ポリモーフィズムと野菜炒め
2020年4月6日、月曜日。 珍しく午前中に起床。サボり気味だった掃除洗濯を早めに済ます。早めに買いものを終えて、ホットクックでいくつか常備菜を準備。
午後は『[Clean Architecture](/tags/Clean Architecture) 達人に学ぶソフトウェアの構造と設計』を読みなおすことにした。とりあえず第Ⅰ部。
-
第1章: 設計とアーキテクチャ* ソフトウェアの設計＝アーキテクチャは、システム構築・保守にかかるリソースを最小限に抑えることを目的とする* 「動くものを作る」姿勢だと、時間経過に応じてチーム・プロダクトの生産性は落ちていく* そのようにして生産性が落ちたプロダクトは、スクラッチから再設計されても同じように崩壊するだろう* 第2章: 2つの価値のお話* ソフトウェアは、「振る舞い（仕様）」と「アーキテクチャ」の2つの価値を持つ* 現場では「振る舞い」が優先されるが、 「アーキテクチャ」を優先させなければならない* 「完璧に動作するが変更できないプログラム」と「動作しないが変更の用意がプログラム」のどちらがよいか？
-
「アーキテクチャ」は第Ⅱ領域、「振る舞い」は第Ⅲ領域* 開発者はステークホルダーとしてビジネスマネージャー（最近なら「プロダクトオーナー」だろうか）と闘争し、アーキテクチャの重要性を伝える責務があるそして第Ⅱ部。
-
第3章: パラダイムの概要* 3つのプログラミングパラダイムは、「何をすべきでないか」という枠組みを提供した* 「構造化プログラミング」は、直接的な制御の移行に規律を課す* 「オブジェクト指向プログラミング」は、間接的な制御の移行に規律を課す* 「関数型プログラミング」は、代入に規律を課す* 3つのパラダイムは、アーキテクチャの重要な関心事とそれぞれ対応する* 構造化: 機能（の分割）
-
オブジェクト指向: コンポーネントの分離* 関数型: データ管理* 第4章: 構造化プログラミング* 構造化プログラミング以前、goto文の時代は、プログラムの処理はあちこちへ飛んでいた。そのためモジュールの分割、それぞれのモジュールの証明（テスト）ができなかった* 構造化プログラミングは、goto文を「順次」、「選択(if/then/else)」、「反復(do/while)」で置き換える発想である* 構造化によりプログラムは大きな機能を小さな機能に無限に分割することができた。今日のプログラミングはこれが基本* モジュールを分割することで、分割された機能は「反証可能」なものになった* 科学が「真であること」を証明できないように、テストも「正しく動作すること」を証明できない。可能なのは「誤った動作をすること」を証明することである（感想: だからTDDはfailから書き始める）
-
第5章: オブジェクト指向プログラミング* 優れたアーキテクチャの基本は、オブジェクト指向設計の原則と似ている* オブジェクト指向の重要な点は、 ポリモーフィズム を安全に提供することにある* ポリモーフィズムによって、上位モジュールが下位モジュールに依存していた関係性を逆転することができる（依存関係逆転）
-
プラグイン・アーキテクチャ（OSは個別のIOデバイスに依存しないようにする）を元にした発想* ポリモーフィズムを利用することで開発者は、依存関係を制御の流れと関係なく好きなように制御できる* 依存関係を逆転・制御することで、一緒くたになっていたコンポーネントを独立してデプロイ・開発することができるようになった* 第6章: 関数型プログラミング* 関数型プログラミングの特徴は、可変変数を持たないことだ* 可変変数を持たないことで、競合・デッドロック・並行更新のトラブルを排除することができる* この「不変性」を実際に使うためには、サービスを「可変コンポーネント」と「不変コンポーネント」に分離させることが重要* （第3章からのまとめでを含めて）ソフトウェアは、「順次」「選択」「反復」と「間接参照」で構成されている。
とくにポリモーフィズムが大事だということがハッキリと伝わってくる。アナロジーを思いついたのでnoteポリモーフィズムと野菜炒め〜『クリーン・アーキテクチャ』を理解するためにを寄稿してみた。
---それでPythonで依存関係の制御を行おうと、実際のコーディングを勉強。Inject と Injectorの2つのライブラリがよく使われているみたいで、とりあえず Inject から使ってみようか。次の2つのQiitaをもとに勉強する。
-
[Python で DDD するなら Inject がオススメ](https://qiita.com/ledmonster/items/3b108be6f0967bfe1093)
