ポリモーフィズムと野菜炒め〜『クリーン・アーキテクチャ』を理解するために

野菜炒めを作ろう。レシピを２つ用意した。

レシピ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 達人に学ぶソフトウェアの構造と設計

というわけで『クリーン・アーキテクチャ』を読み込みやすくすることを目的に、たとえ話を考えてみました。

「一家に一冊」系の技術書だと思っています。未読のプログラマは是非。

Clean Architecture 達人に学ぶソフトウェアの構造と設計