ポリモーフィズムと野菜炒め〜『クリーン・アーキテクチャ』を理解するために
野菜炒めを作ろう。レシピを2つ用意した。
レシピA
レシピAは「定番の野菜炒めの作り方」を紹介している。
1. キャベツの葉を50g、にんじんを50g、玉ねぎを100g、豚肉を100g用意する。玉ねぎ、にんじんは5mm幅に切り、キャベツは1枚を6等分する。
2. 20cm経のフライパンを用意して、サラダ油を5mlたらす。底にあたらない程度の火加減で30秒熱する。
3. まずにんじんを入れて2分熱したら、つぎにキャベツを入れて1分30秒加熱する。そして玉ねぎを入れてさらに1分加熱する。最後にしょうゆ小さじ1/2、塩1gを入れて強火で30秒加熱する
このレシピはとても丁寧だ。(実際にこの工程でやっても美味しくはならないだろうが)準備する野菜の種類も、その量も、調理工程も書かれている。私はこの通りに手を動かすだけでいい。
レシピB
レシピBは、もっと適当だ。
1. 適用な野菜、肉を用意して、食べやすいサイズに切る
2. フライパンに油をひいてあたためる
3. 食材を炒め、火が通ったら調味料を入れて味付けする
このレシピはひどく不親切かもしれない。料理初心者にとっては何の情報もないゴミと扱われるだろう。
レシピ本の改定
このあと「定番の野菜炒めの作り方」に変化があった。
どうやら、食材にもやしを追加して、油はごま油を使い、にんじんはもう少し細く切り、隠し味にラー油を使うと美味しくなるらしい。
このときレシピAは改定を余儀なくされた。
しかしレシピBは、元の版のまま売り続けることができた。
なぜならレシピBは、詳細な作り方を「捨象」して、「あいまい」な作り方だけを載せていたからだ。
ポリモーフィズム
レシピAは、調理の「工程」それぞれに「実際の作業」がくっついていた。
レシピAに書かれた動作以外は許されず、誰がつくっても同じ結果になることが期待されている。
一方でレシピBは「工程」を載せただけで「実際の作業」は料理する我々が考えなければならない。
そのため皿に載せられた野菜炒めには多様性が生まれる。
言い換えればレシピBの「工程」は、ポリモーフィズムを実現しているのだ。
依存関係の逆転
もうひとつ重要なことを確認しておこう。
レシピAは、トレンドや監修者が変わって「実際の作業」が変われば、「工程」も変わり、結果としてレシピ本の版を変えざるを得ない。
つまり「工程」が「実際の作業」に依存していることがわかる。
しかしレシピBは、「工程」に沿って「実際の作業」を考える必要がある。
つまり「実際の作業」が「工程」に依存している。
レシピ本の書かれ方ひとつで、依存関係が逆転するのだ。
『クリーン・アーキテクチャ』とポリモーフィズム
『クリーン・アーキテクチャ』では、ポリモーフィズムそして依存関係の逆転(制御)によって次のメリットがあることを示している。
たとえばシステムのソースコードの依存関係を並べ替えるだけで、他の方法を使わなくてもデータベースとユーザーインターフェイス(UI)をビジネスルールに依存させることができる。[...]
つまり、ビジネスルールを含むコンポーネントは、UIやデータベースを含むコンポーネントに依存しないということだ。[...]
また、ビジネスルールは、UIやデータベースとは独立してデプロイできる。システムにあるモジュールを個別にデプロイできるなら、別々のチームが個別に開発できる。これが、独立開発可能性である。
レシピBは、「工程」と「実際の作業」の依存関係を逆転させたことで、野菜炒めは家庭ごとに独立して作らせるようにして、レシピ本としての柔軟性が高くなった、と言えよう。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
というわけで『クリーン・アーキテクチャ』を読み込みやすくすることを目的に、たとえ話を考えてみました。
「一家に一冊」系の技術書だと思っています。未読のプログラマは是非。
この記事が気に入ったらサポートをしてみませんか?