1.依存関係逆転の原則
高レベルのモジュールは低レベルのモジュールに依存せず、両方とも抽象化に依存する必要があります
抽象化は実装の詳細に依存せず、実装の詳細は抽象化に依存する必要があります
。この原則は、実装プログラミングではなく次のインターフェイス プログラミングと同じです。プログラムを設計するときは、最初に実装方法を考えるのではなく、何を抽象化したいのか、どのような機能を持たせる必要があるのかを最初に考えるべきです。具体的なメソッド、そして最後に作成した具体的な実装に基づいて、最終的なインターフェイスが何であるかをまとめます。
2 オープンとクローズの原則
延長の場合はオープン、変更の場合はクローズ
クラス モジュールは拡張可能である必要がありますが、変更することはできません。
界面を定義した後は、界面層の安定性を可能な限り確保する必要があります。
3 単一責任の原則
クラスを変更する理由は 1 つだけである必要があります
変更の方向はクラスの責任を意味しており、
クラスの変更が多すぎるとプログラムのメンテナンスが困難になったり、クラスのインターフェース部分が変更される可能性があり、上記の2番目の原則に違反します。
変更内容 (使用される具体的な実装など) のうち、この部分の具体的な目的を明確にする必要があります。
4 リスコフ置換原理
サブクラスは、その基本クラスを置き換えることができる必要があります。
式の型の抽象化を継承します。
サブクラスが基本クラスを置き換えることができない場合、ほとんどの設計パターンは役に立ちません。
5 インターフェイス分離の原則
クライアントは、使用していないメソッドに依存することを「強制」されるべきではありません。
インターフェイスは小さく、完全なものである必要があります。
オブジェクトを設計するときは、そのオブジェクトにどのような機能を含めるべきかを明確に理解し、対応するインターフェイスを作成し、顧客が使用しない他のメソッドをすべて非表示にする必要があります。
6 クラス継承よりもオブジェクト合成を優先する
ホワイト ボックスの再利用: 親クラスのすべてのコンテンツをサブクラスに公開します。
ブラック ボックスの再利用: 公開したい部分のみを公開し、コンテンツの残りの部分はそのクラスには表示されません。
***クラスの継承* は、ホワイト ボックスの再利用と呼ばれることがよくあります。
*** オブジェクトの構成* は、ブラック ボックスの再利用と呼ばれることがよくあります。
継承によりカプセル化がある程度崩れ、サブクラスと親クラスの結合度が高い
オブジェクトの合成では、合成されるオブジェクトが明確に定義されたインターフェイスを持つことのみが必要です。
パッケージの7つ の変更点
カプセル化を使用してオブジェクト間に境界層を作成すると、
設計者は変更の反対側に悪影響を与えることなく変更できるようになり、
層間の疎結合が実現します。
8. 実装ではなくインターフェイスに対するプログラム
変数の型を特定の型の具象クラスとして宣言する代わりに、インターフェイスとして宣言します。
クライアント プログラムはオブジェクトの特定のタイプを知る必要はなく、オブジェクトが持つインターフェイスだけを知る必要があります。
システム内のさまざまな部分の依存関係を減らし、 「高い凝集性と疎結合性」の型設計スキームを実現します。