3つのプログラミングパラダイム

構造化プログラミング

構造化プログラミングとは、「順次（上から順にプログラムを実行する）」「反復（for文）」「分岐（if文）」の３つの構造を使ってプログラム構築こと。

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

継承

同じようなものをまとめて、それを再利用できるようにすること

設計の原則

SOLID原則

S：単一責任の原則（Single Responsibility Principle）
O：解放閉鎖の原則（Open/Closed Principle）
L：リスコフの置換原則（Liskov Substitution Principle）
I：インタフェース分離の原則（The Interface Segregation Principle）
D：依存性逆転の原則（Dependency Inversion Principle）

単一責任の原則

「1つのクラスに対して1つの役割」
→クラスを変更する理由が2つ以上存在してはならない

解放閉鎖の原則（オープン・クローズドの原則）

「クラスは拡張に対して開いていて、修正に対して閉じていなければならない」
→オープン=拡張が出来る、クローズド=修正する場合はそのクラスだけ修正すればいい

リスコフの置換原則

「基本クラスを使っている場所で基本クラスの代わりにサブクラスを使っても問題なく動かなけらばならない」
→

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

「クライアントに、クライアントが本来依存しないメソッドへの依存性を強制してはならない」
→

依存性逆転の原則

「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである」
→

コンポーネントの原則

コンポーネント

コンポーネント=デプロイの単位のこと

コンポーネントの凝集性

凝集性

凝集性=集合体の統合性の強さ
凝集性が高い（機能と機能の関わり具合が低い）ほど良いプログラムとされる

再利用・リソース等価の原則

「リリースの単位が再利用の最小単位」
→再利用の単位はリリースの単位と同一であるべきである。コンポーネントを再利用するには、コンポーネントのリリース単位で行う
コンポーネントに含まれるクラスは、すべてが再利用されるか、すべてが再利用できないかのどちらかにすべき
ex.) Javaのクラスを修正した場合、クラス単位ではなくjar単位でリリース・再利用を行うのが理想

閉鎖性共通の原則

「同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分ける」
→コンポーネントを変更する理由が複数あるべきではない。同じ理由、同じタイミングで変更されることが多いクラスは1つのコンポーネントにまとめておくべき。

全再利用の原則

「1つのクラスだけを再利用するということはめったになく、複数のクラスと組み合わせて使われることがほとんどのため、そうしたクラス群は1つのコンポーネントにまとめる」

コンポーネントの結合

非循環依存関係の原則

「コンポーネントの依存グラフに循環依存があってはならない」

安定依存の原則

「安定度の高い方向に依存すること」
→安定度の高い=変更がしづらい

安定度・抽象度等価の原則

「コンポーネントの抽象度は、その安定度と同程度でなければならない」
→安定度の高いコンポーネントは抽象度も高くあるべき

プログラミングMEMO

【勉強まとめ】Clean Architecture 達人に学ぶソフトウェアの構造と設計