単一責任の原則
定義: クラス変更の理由は複数あってはならない。平たく言えば、クラスは 1 つの責任だけを担当します。
リヒター置換原理
定義 1: T1 型のすべてのオブジェクト o1 に対して、T2 型のオブジェクト o2 が存在する場合、T1 で定義されたすべてのプログラム P は、When allオブジェクト o1
が o2 に置き換えられると、プログラム P の動作は変わりません。その場合、型 T2 は型 T1 のサブタイプになります。
定義 2: 基本クラスを参照するすべての場所で、そのサブクラスのオブジェクトを透過的に使用できなければなりません。言い換えれば、基本クラスが出現できる場所には必ずサブクラスが出現する可能性があります
。
平たく言えば、リヒター置換原理とは、サブクラスは親クラスの機能を拡張できますが、親クラスの元の機能を変更することはできないことを意味します。これには次の 4 つのレベルの意味が含まれます:
1) サブクラスは親クラスの抽象メソッドを実装できますが、親クラスの非抽象メソッドをオーバーライドすることはできません。
2) サブクラスは独自のメソッドを追加できます。
3) サブクラスの メソッドが親クラスのメソッドをオーバーライドする場合、メソッドの前提条件 (つまり、メソッドの仮パラメータ) は、親クラスのメソッドの入力パラメータよりも緩くなります。
依存関係逆転の原理の核となる考え方は、インターフェース
依存関係を転送するには、1.インターフェースの転送、2.コンストラクターメソッド
の転送、3.セッターメソッドの転送の3つの方法があります。
実際のプログラミングでは、通常、次の 3 つの点を行う必要があります:
1) 低レベルのモジュールには、抽象クラス
、またはその両方が必要です。
2) 変数
の宣言された型は、可能な限り抽象クラスまたはインターフェイスである必要があります。
3) 継承
を使用する場合は、リスコフ置換原則に従います。
インターフェース分離原則
大規模な全体的なインターフェイスを提供するのではなく、できる限り小さい個々のインターフェイスをクライアントに提供する必要があります。
1) 単一の一般的なインターフェイスよりも、複数の特殊なインターフェイスを使用する方が優れています。
2) あるクラスの別のクラスへの依存は、最小のインターフェイスに基づく必要があります。
3) インターフェイスはロールを表し、異なるロールを 1 つのインターフェイスに割り当てないでください。関係のないインターフェイスが結合されて、大きく肥大化したインターフェイスが形成され、ロールとインターフェイスが汚染されます。
4) 「クライアントは、使用していないメソッドに依存することを強制されるべきではありません。インターフェイスは、それが配置されているクラス階層ではなく、クライアントに属します。」これは明らかであり、より一般的に言えますが、顧客が使用していない方法の使用を強制しないでください。ユーザーに使用しない方法の使用を強制すると、これらの方法の変更によって顧客は変化に直面することになります。彼らは使いません。
Demit Principle
定義: オブジェクトは他のオブジェクトについての最小限の知識を保持する必要があります。
明らかに、インターフェイス分離原則と一般化された Dimit 原則は、1 つのソフトウェア エンティティと他のソフトウェア エンティティの間の通信に対する制限です。一般化されたデメテル原則では、
はコミュニケーションの幅と深さを可能な限り制限する必要があります。インターフェイス分離の原則によって制限されるのは通信の幅です。つまり、通信は可能な限り狭くする必要があります。
デメテルの法則は、最も知られていない原理とも呼ばれ、1987年に米国のノースイースタン大学のイアン・ホランドによって初めて提案されました。平たく言えば、クラスが依存するクラスについての知識が少ないほど良いことを意味します。つまり、依存するクラスは、どんなに複雑なロジックであっても、ロジック
を可能な限りクラス内にカプセル化し、提供されるpublicメソッド以外には情報が外部に漏洩しないようにする。デメテルの法則にはもっと簡単な定義があります: 直接
している友達とのみ通信する。まず、直接のフレンドとは何かについて説明します。各オブジェクトは他のオブジェクトとカップリング関係を持ちます。2 つのオブジェクト間にカップリング関係がある限り、その 2 つのオブジェクトはフレンドであると言われます。結合には、依存関係、関連付け、結合、集約など、さまざまな方法があります。このうち、メンバー変数、メソッドのパラメータ、メソッドの戻り値に現れるクラスを直接の友達と呼びますが、ローカル変数に現れるクラスは直接の友達ではありません。言い換えれば、馴染みのないクラスがローカル変数としてクラス内に出現しないことが最善です。
オープンとクローズの原則
ソフトウェアエンティティは、拡張に対してオープンであり、変更に対してクローズである必要があります。
再利用の目的を達成するには、継承関係の代わりに組み合わせ/集合を使用するようにしてください。
以上がデザインパターンの6つの原則の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。