Clean Architecture 第4章〜第5章
（この記事は前回の続きです）
構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミングが不変のパラダイムであるということを前回までに学んだので、今回と次回はこの3つのより詳細な解説を見ていこう。
構造化プログラミング
まだプログラマという職業が全く認知されていない時代、つまり真空管を使った巨大なコンピュータにパンチカードで入力している時代。プログラミングが全くうまく管理できていない、つまりバグなどが出まくることを問題と認識したDijkstraは、数学の証明の方法、より具体的にはすでに実績のある（証明された）構造をプログラマが使用することで、このうまく管理できていない状況を救えないかと考えた。そして数学的証明を使用し、「順次」「選択」「反復」といった制御構造のみを使用したモジュールならば分割統治可能、つまり大きな課題（機能追加）をモジュールやコンポーネントに分割し、さらに小さな証明可能な機能に細分化することで安全性を担保可能（反証可能性を検証）しうることができるようになることを証明した。今日ではそもそもこの制御構造の上でしかプログラミングできない言語が大多数であり、自分もDijkstraさんの功績の恩恵を存分に受けていることになる。
オブジェクト指向プログラミング
なんだかんだでわかったようなわからないような話になりがち（？）なオブジェクト指向プログラミング。これってなんなのだろうか。現実世界を抽象化、、わかったようなわからないような。
カプセル化と継承とポリモーフィズムの混合物と呼ぶ人もいるが、さて。そもそもこの3つの概念、なんでしたっけ？
カプセル化は「プライベートなデータメンバー」と「クラスのパブリックなメンバー関数」としてデータと関数の周囲に境界線を引くことができるもので、オブジェクト指向プログラミングはそれを簡単かつ効果的なものにしている。とはいえ（詳しくは本書に例示的なコードが載っているので読んでいただきたいが、）C言語の時代からカプセル化は行われている。しかしながら、ほとんどのオブジェクト指向言語はカプセル化を強制しておらず、むしろC言語に比べて弱体化させてしまっている。
継承はスコープ内の変数と関数のグループを再度宣言したものである。まあ、要は（というと語弊があるし、本書のコードベースで理解してほしいが）再利用できるようにする話であるが、これも単一継承ならC言語でもよく使われたテクニックである。
ポリモーフィズムは様々な入出力（引数の数や、返却値の型の違いなど）のバリエーションに対応できることを指すが、これも今まで関数のポインタを使用してきた。つまりオブジェクト指向が新しく提供したわけではない。一方、関数のポインタへアクセスするのは初期化などを考慮すると危険とされており、オブジェクト指向プログラミングによってその安全性は担保され、熟練したプログラマでないと扱いづらかった部分をもっと一般に開放したと言える。
これをプログラムの制御構造と依存（継承）関係で考えてみると、安全で便利なポリモーフィズムが扱えるようになると逆転できる「依存関係逆転」が可能になり、それを使ってビジネスルールにUIとDBを依存させることが容易にできるようになったのである。
これは近年のモノシリックではないアーキテクチャ、例えばAPIを介したフロントエンドとバックエンドの分離にも通じる考えだと言えるし、プラグインアーキテクチャとも言える。RailsやCakePHPの（当初流行した）デザインパターンであるMVCにも通じており、プログラマやってて実際に恩恵を受けているこの考え方、改めて学んでみるとなるほどと思わされる。
さて、次回はいよいよ近年再び脚光を浴びつつある関数型プログラミングについて学びつつ、さらに様々な設計の原則を学ぶ旅となりそうだ。徐々に核心に迫って行きつつあるこの旅路、引き続きお付き合いいただければ幸いである。
この記事が気に入ったらサポートをしてみませんか？