序文
デザインパターンでよく使われる7つの設計原則
単一責任の原則
クラスの場合、クラスは 1 つの責任のみを担当する必要があります
クラスが 2 つの責任を担う場合、一方の責任の要件が変更され、クラスを変更する必要がある場合、もう一方の責任の実行でエラーが発生する可能性があるため、クラスを分解する必要があります。
単一責任原則を実装するために、やみくもにクラスを分解する必要はありません。やみくもにクラスを分解すると、クラスが増えすぎて過剰なコストが発生します。クラス内のメソッド レベルで単一責任原則を実装することも考慮する必要があります。もちろん、その数はメソッドの数も増えます。
インターフェース絶縁原理
クライアントは、必要のないインターフェイスに依存すべきではありません。あるクラスの別のクラスへの依存関係は、最小のインターフェイスに基づく必要があります。
シーン
インターフェイスには 5 つのメソッドがあります。クラス C とクラス D はインターフェイス インターフェイスを実装しており、これら 5 つのメソッドを実装する必要があります。次に、クラス A はインターフェイスを通じてクラス C に依存しますが、クラス A はインターフェイス内でメソッド 1 と 4 のみを使用します。クラス B はインターフェイスを通じてクラス D に依存しますが、クラス B はインターフェイスの途中でメソッド 1、2、および 3 のみを使用します。これにより、クラス C と D が必要のないメソッドを実装しなければならない状況が生じます。
原則によれば、次のように処理する必要があります。インターフェイスをいくつかの独立したインターフェイスに分割し、クラス A とクラス B がそれぞれ必要なインターフェイスとの依存関係を確立します。具体的には、インターフェイスは 3 つのインターフェイスに分割されます。1 つのインターフェイスにはメソッド 1 が含まれ、1 つのインターフェイスにはメソッド 4 と 5 が含まれ、残りのインターフェイスにはメソッド 2 と 3 が含まれます。次に、C で最初と 2 番目のインターフェイスを実装し、D で最初の 3 つを実装します。インターフェース
依存関係逆転の原理
設計思想: 細部の変動に比べて、抽象的なもののほうが安定している; 抽象化に基づいたアーキテクチャは、細部に基づいたアーキテクチャよりもはるかに安定している Java では、抽象化はインターフェイスと抽象クラスであると言えます。実装クラスの詳細です。具体的なものではなく抽象的なものに頼るべきです
依存関係の配信方法には、インターフェース配信、コンストラクターメソッド配信、セッターメソッド配信の3 つがあります。
注意事項:
- 低レベルのモジュールには、抽象クラスまたはインターフェイス、あるいはその両方を含めるようにする必要があります。
- 宣言された変数の型は、変数参照と実際のオブジェクトの間にバッファ層が存在するように、可能な限り抽象クラスまたはインターフェイスにする必要があります。これは、プログラムの拡張と最適化に役立ちます。
- 継承するときはリスコフ置換原則に従います
リヒター置換原理
OO の継承について
- 継承の意味は、親クラスに実装されたメソッドが実際に仕様や規約を定めているということで、すべてのサブクラスがこれらの規約に従うことは必須ではありませんが、実装されたメソッドをサブクラスが勝手に変更すると、システムに損害が発生します。継承システム全体。
- 継承の欠点は、継承を使用するとプログラムに侵入が生じ、プログラムの移植性が低下し、オブジェクト間の結合が増加することです。クラスが他のクラスによって継承される場合、クラスが必要なときにすべてのサブクラスを考慮する必要があります。また、親クラスが変更されると、サブクラスに関係するすべての関数が誤動作する可能性があります。したがって、String のようなコア クラスは継承できません。
リスコフ置換原則と同等のものは、基底クラスを参照するすべての場所で、そのサブクラスのオブジェクトを透過的に使用できなければならない、つまり、親クラスの参照が親クラスではなくサブクラスのオブジェクトを指すように変更された場合に使用できる必要があります。オブジェクト、プログラムの動作に変更はありません。このため、継承を使用する場合は、サブクラスで親クラスのメソッドをオーバーライドしないようにする必要があります。
シーン
クラス A とクラス B があるとします。B は A を継承し、A のメソッドをオーバーライドします。このとき、次のように処理する必要があります。A と B の上に
基本クラスを作成し、A と B の両方ができるようにします。この基本クラスにより、A と B の間の分離が可能になります。後で B が A のメソッドを呼び出したい場合は、集約、依存関係、組み合わせなどを使用して実装できます。たとえば、クラス A のメンバー変数を B に作成し、 then B クラス オブジェクトは、この A 変数を呼び出すことによって A のメソッドを呼び出します。
開閉原理 ocp (開閉原理)
オープンクローズの原則は、プログラミングにおける最も基本的かつ重要な設計原則であり、クラス、モジュール、関数などのソフトウェア エンティティは、拡張に対してオープンであり、変更に対してクローズである必要があります。ソフトウェアを変更する必要がある場合は、既存のコードを変更するのではなく、ソフトウェア エンティティの動作を拡張することによって変更を実現するようにしてください。
フレームワークは抽象的であり、実装するときに詳細を拡張する必要があります。
デメテルの法則
最も知られていない原則とも呼ばれます。つまり、クラスが依存するクラスについて知っていることが少ないほど良いということです。言い換えれば、依存するクラスの場合、それがどれほど複雑であっても、クラスをカプセル化するようにしてください。内部のロジックと外部の Public メソッドを提供しますが、情報は提供しません
デメテルの法則の定義はより単純で、「直接の友人とのみ通信する」というものです。2 つのオブジェクト間に結合関係がある限り、それらをフレンドと呼びます。結合方法には、依存関係、関連付け、結合、集約などが含まれます。その中で、メンバー変数、メソッドのパラメーター、メソッドの戻り値を持つクラスをクラスと呼びます。直接の友達、ローカル変数に現れるクラスは直接の友達ではない、つまり、馴染みのないクラスがローカル変数としてクラスに現れないことが最善です。
ディミットの法則の核心は結合を減らすことであり、依存性がまったくないという意味ではありません。
合成再利用の原則
継承の代わりに結合または集計を使用してみてください
B で構成される A などの組み合わせは、A に B のグローバル オブジェクト (ローカル変数) が含まれており、A の作成時に B も作成されるという事実によって表されます (インスタンス化は、 型のローカル変数を宣言するときに使用されnewます) B in A ;ただし、プログラム内の A が B のカスケード削除を定義している場合、A は B も結合します)。全体と部分は切り離せない
A が B を集約するなどのAggregation は、A が B への参照を持つ可能性があるが、A の作成時に B は作成されないことを意味します。メソッド (型 B のローカル変数を宣言しますが、変数を代入せずに宣言するだけ) によって作成される可能性がありますset。価値）。全体とその部分を分離することができます。結合は集計よりも結合されており、集計/結合された変数のライフサイクルを決定するかどうかが、この 2 つの大きな違いです。
デザインパターンの目的
- コードの再利用性
- 可読性
- スケーラビリティ（保守性）
- 信頼性
- 高い凝集性と低い結合性