開閉の原則
- モジュール、クラス、関数などのソフトウェア・エンティティは、変更に対してクローズドであり、拡張に対してオープンであるべきです。
リヒターの置換原理
継承のデメリット
あるクラスが他のクラスから継承されている場合、そのクラスを変更する必要があるときに、すべてのサブクラスを考慮する必要があり、オブジェクト間の結合が増加します。
リヒターの代替わりの原則は、継承を支配する原則です；
親クラスが出現できるところには、サブクラスも出現できなければなりません。サブクラスは親クラスの抽象メソッドを実装することができ、親クラスの非抽象メソッドをカバーするためにオーバーライドしないようにします；
サブクラスは、親クラスの上に自分自身を拡張する必要があります；
ディミトリの原則。
オブジェクトは、他のオブジェクトに関する最小限の知識しか持たないべきです。
直接の友人とだけ連絡を取り合いましょう：
- メンバ変数、メソッド・パラメータ、メソッドの戻り値に現れるクラスは、直接の友人です。
- ローカル変数に現れるクラスは直接の友達ではなく、相互呼び出しの関係を作らないようにします。
単一の責任
- クラスが担当する責務は1つだけなので、機能を修正する際に他のモジュールへの影響を大幅に軽減できます。
インターフェース分離の原則
- 汎用的なものを使うよりも、特定のクライアントに関連したインターフェイスを使う方が良いでしょう。
- あるクラスと別のクラスとの依存関係は、巨大で肥大化したインターフェースではなく、最小限のインターフェースで構築されるべきです。
依存関係逆転の原則
- 上位のモジュールは下位のモジュールに依存すべきではありません。
- 抽象化は詳細に依存すべきではなく、実装の詳細は抽象化に依存すべきです。
抽象：プロトコル、抽象クラスなど
詳細：具体的な実装クラス
VII.組合せ再利用／集合再利用の原則
- ソフトウェアの再利用には、継承よりも組み合わせや集約を使用するようにしてください。
集約：全体のライフサイクルと部分のライフサイクルが一致しない場合がある、全体と個の関係。
結合：部分のライフサイクルが全体のライフサイクルと一致する、集合よりも強い関係。
