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

どんなことが書かれているかとりあえずずらずらと書きます
* あとでまとめて編集

第1章: 設計とアーキテクチャ

• 設計とアーキテクチャの違いはない
  設計はアーキテクチャの詳細を表すことでアーキテクチャをサポートするもの。
  一方でアーキテクチャとそれをサポートする設計の連続で全体の一部が作られ結果的にシステムの形状が定義される一面もあるため、明確に区別できない

• 設計とアーキテクチャの目的
  その目的は求められるシステムを構築・保守するために必要な人材を最小限に抑えること。
  したがってその良し悪しは労力がいかに費やされたかで決まる。
  リリースごとに労力が増えるのであれば優れていない。
  ケーススタディを交えて説明

第2章: 2つの価値のお話

• ソフトウェアシステムとは「機能」と「アーキテクチャ」の2つの異なる価値をステークホルダーに提供するものであり、開発者はこれを維持する責任があると説明した上で最終的にどちらのほうが大きな価値があるかを問い、それは構造であると結論づけている。

第2部 プログラミングパラダイム

第3章: プログラミングパラダイムの概要

構造化プログラミング・オブジェクト指向プログラミング・関数型プログラミングの3つについて軽く説明
パラダイムはアーキテクチャの3つの大きな関心事「コンポーネントの分離」「データ管理」「機能」に対応している

第4章 構造化プログラミング

構造化プログラミングとはどういうものか

第5章 オブジェクト指向プログラミング

• 現代の主流なパラダイム。
• 優れたアーキテクチャの基本となるのはこの“オブジェクト指向“の原則の理解と適用。
• オブジェクト指向とはなんなのか

オブジェクト指向とは

俗説によると
① データと関数の組み合わせ：☓
② 現実の世界をモデル化する方法： ☓
③ カプセル化・継承・ポリモーフィズム: △

結論どれもちがーうw

• カプセル化：☓
  データと関数のカプセル化を簡単かつ効果的なものにしていて、その結果、見えないデータと見える一部の関数がある。
  この概念は「プライベートなデータメンバー」と「クラスのパブリックな関数メンバー」として表される
  ただこの考え方はオブジェクト指向言語以前からC言語で存在していた。むしろ完璧なカプセル化だった
  C++というオブジェクト指向言語が登場し、それ以降C言語による言語の完璧なカプセル化が破壊・弱体化してしまった。したがってカプセル化をオブジェクト指向であると定義づけることはできない。

• 継承：☓
  C言語にも存在していて、C言語プログラマが手動でやっていた。
  本物の継承と比べるとさほど便利でなかったし、多重継承を実現するのはかなり困難であるため違うところもあるが、
  オブジェクト指向が発明されるずっと昔から存在するためこれも違う。

• ポリモーフィズム：△
  ポリモーフィズムも新しい考えではない。つまりオブジェクト指向は新しいものを提供しているわけではない。
  ただし、これが全面的に正しいわけでもない。
  オブジェクト指向がポリモーフィズムを提供してくれたわけではないが、これを安全かつ便利にしてくれたのはオブジェクト指向だ。
  このポリモーフィズムを利用することで、コンポーネントの依存関係を独立させることができ、さらにその依存関係を制御(逆転)させることができる。
  その結果、UIのコンポーネント、DataBaseのコンポーネントをビジネスルールに依存させることができる。
  またUIやDataBaseに変更があっても、ビジネスルールとは独立して変更することができる。

結論： オブジェクト指向とは「ポリモーフィズムを使ってソースコードの依存関係を制御すること。

第6章：関数型プログラミング

・関数型言語の変数は変化しない(不可変変数)
・可変変数が存在しなければ競合状態・デッドロック状態・並行更新の問題は発生し得ない
・適切に構造化されたアプリケーションでは、可変コンポーネントと不変コンポーネントの切り分けがしっかりとできている。

結論：関数型プログラミングは代入に規律を課すものである。

第2部まとめ

・構造化プログラミングは直接的な制御の移行に規律を課すもの(goto文に順次・反復・選択)
・オブジェクト指向プログラミングは間接的な制御の移行に規律を課すもの(依存関係逆転)
・関数型プログラミングは代入に規律を課すもの(不変コンポーネント)

これらのパラダイムは何か力を与えてくれるものではない。
「何をすべきでないか」を示してくれている。
ソフトウェアでは昔から「順次」・「反復」・「選択」・「間接参照」で構成されている

オブジェクト指向のポリモーフィズムを理解するのにかなり時間がかかったし
今でも依存関係逆転ってどこが逆転してるの？って感じが拭えない。
とりあえずまず広く浅く全体像を掴むことにする(気になってむずむずする)

第３部 設計の原則

よくできたソフトウェアシステムを作るにはクリーンなコードを書いてよりよい優れたモジュールを作ることから始まる。
これはレンガの出来が悪ければ優れた建築はできないのと同様である。
(もちろんたとえよくできたレンガを使っても、それ以降の作業でぐちゃぐちゃなものを作ってしまうこともあり得るが。)
第３部ではよりよいレンガ、つまり、変更に強い・理解しやすい・コンポーネントの基盤として多くのソフトウェアシステムで利用できるモジュールを作るために必要なSOLIDについて説明されている。(それ以降の上位レベルのアーキテクチャの原則については第３部以降で説明。)

第7章 単一責任の原則

• 「ひとつの関数はたったひとつのことだけを行うべき」という考えではない
• 「ソースファイルはたったひとつのアクターに対して責任を負うべきであり、アクターの異なるコードは別のファイルに分割するべき」という考え

第８章 オープン・クローズドの原則

・既存の成果物を変更せずシステムを拡張しやすくする、という考えであり、ソフトウェアアーキテクチャを学ぶ根本的理由。ちょっとした拡張・変更のために既存のコード書き換えが大量に必要になるようなら、それは失敗へ進んでいる。

・オープン・クローズドの原則というと、クラスやモジュールを設計する際の指針だと考えている人が多いが、コンポーネントのレベルを考慮したときに重要味を増すと述べていて、8章ではその証明をしている。

第９章 リスコフの置換原則

・スーパークラスにない関数をサブクラスで作るな、スーパークラスの関数を無視するな
・置換原則に違反したときに何が起こるか

第10章 インターフェイス分離の原則

必要としないお荷物まで抱えたものに依存していると予期せぬトラブルの元につながるから、その際は必要なものだけを持つインターフェイスに分離しよう。