オブジェクト指向はプログラミングのパラダイムではない #ポエム

『エリック・エヴァンスのドメイン駆動設計』（以後、DDD本）を読んで思ったことのメモ。

オブジェクト指向はモデリングのパラダイムである

DDD本を読んで自分の中ですごく腑に落ちたのは、「オブジェクト指向はプログラミングのパラダイムではなく、モデリングのパラダイムである」ということ。

「オブジェクト指向のメリットは、現実をそのまま表現できること」と言われることがある。
これは、オブジェクト指向のモデリングパラダイムとしての側面を捉えた表現だ。

オブジェクト指向に限らず、リレーショナルモデルでも統計モデルでも、モデルというのは「現実世界の物事を、ある捉え方で表現したもの」みたいな定義だ。

現実世界の物事を「属性（フィールド）」と「振る舞い（メソッド）」の塊としてモデル化のがオブジェクト指向モデルだ。

「現実をそのまま表現する」と複雑すぎるので、オブジェクト指向モデルだったりリレーショナルモデルだったりで表現して整理するのだ。

モデル化せずにコンピュータの考え方でアプリケーションを作ろうとすると、ここはこういう分岐でこういうときはこうなって...とめちゃくちゃ複雑になる。

だから、現実世界をモデル化できない構造化プログラミングではなく、現実世界をモデル化できるオブジェクト指向プログラミングが良いとされるのだ。

複雑すぎる現実を単純化するために何らかのモデリングが必要なのだが、その中でオブジェクト指向が選ばれるの理由は以下の2つだ。

オブジェクト指向以外にも、リレーショナル、関数型、論理型など、様々なモデリング手法がある。

そんな中、オブジェクト指向だけは理解のハードルがめちゃくちゃ低い。

クラス図を見ながら「こういう役割のやつがいて、こんなふうに指示を出すんですよ」とか、ITの知識がなくても会話が成り立ちうる。

エンジニアと周りの人を繋ぐ共通言語となり、認識齟齬を減らしうるから、オブジェクト指向が良いとされるのだ。

いくらモデルが分かりやすくても、そのまま実装に落とせなければ、実装時にエンジニアの思い込みが入ってしまう。

オブジェクト指向の素晴らしいところは、モデルとして図に描いたりして議論した内容を、そのまま実装に落とせるところだ。

モデルをそのまま実装に落とすことで、こんなときはきっとこう動くんだろうなーとかも推測しやすくなる。

オブジェクト指向モデルが選ばれる理由は以下の2つだ

オブジェクト指向モデルとは、現実世界の物事を「属性（フィールド）」と「振る舞い（メソッド）」の塊である「オブジェクト」のやり取りで表現するモデルである。

難しいのは、物理的に実体のある物だけでなく、ポリシーのような概念もオブジェクトとして捉えるからだ。

オブジェクト指向はプログラミングではなくモデリングのパラダイムだと理解すると、あることに気付く。

「あれ？マイクロサービスもオブジェクト指向モデルなのでは？」

各サービスに「属性（DB）」を持たせて隠蔽し、「振る舞い（API）」によってやり取りするのは、まさにオブジェクト指向だ。

確かに「マイクロサービスオブジェクト指向」とググると、そういう話がたくさん出てくる。

やはり、オブジェクト指向はプログラミングパラダイムではなく、モデリングのパラダイムなのだ。

マイクロサービス・アーキテクチャには、オブジェクト指向と似たデザインパターンがある。

例えば、Proxyパターンとサイドカー・パターン、FacadeパターンとBackend For Frontendは似ている。

他にも探せばたくさんありそうな気がしてくる。

マイクロサービスを構築するときは、オブジェクト指向の文脈を思い出してみるとヒントになるかもしれない。