PHP デザイン パターン - 6 つの原則_PHP チュートリアル

PHP デザイン パターン - 6 つの原則

一般に、次の 6 つの原則に従うコードは拡張しやすく、再利用しやすいと考えられています。

コードを拡張して使いやすくしたい場合は、これらの 6 つの原則に従う必要があります。必ずしも特定の設計パターンに厳密に従う必要はありません。コードは準拠している これらの 6 つの原則に従うと、コードは優れたコードになります。必ずしも、設計パターンに従って厳密に記述されたコードであるとは限りません。

1.単一責任

定義: クラス変更の理由は複数あってはならない。平たく言えば、クラスは 1 つの責任のみを担当します。

シナリオ: クラス T は、責任 P1 と責任 P2 という 2 つの異なる責任を担当します。責任 P1 の要件の変更によりクラス T を変更する必要がある場合、元々正常に動作していた責任 P2 の機能が誤動作する可能性があります。その関係は次のとおりです。

修正: 単一責任の原則に従います。 2 つのクラス T1 と T2 をそれぞれ作成し、T1 が責任 P1 の機能を完了し、T2 が責任 P2 の機能を完了できるようにします。このように、クラス T1 が変更された場合、責任 P2 は失敗する危険がなく、同様に、T2 が変更された場合、責任 P1 は失敗する危険はありません。

構造は次のとおりです。

利点:

1) クラスの複雑さを軽減できます。各クラスは 1 つの責任のみを担当し、ロジックは単純です。

2) クラスの可読性とシステムの保守性を向上させます。

3) 変化によって引き起こされるリスクは軽減され、変化は避けられません。

2. リヒター置換原理

定義: 基本クラスを参照するすべての場所は、そのサブクラスのオブジェクトを透過的に使用できなければなりません。つまり、サブクラスは親クラスの機能を拡張できますが、親クラスの元の機能を変更することはできません

シナリオ: クラス A によって完了された関数 P1 があります。ここで関数 P1 を拡張する必要があります。拡張された関数は P です。ここで、P は元の関数 P1 と新しい関数 P2 で構成されます。新しい関数 P は、クラス A のサブクラス B によって完成されます。サブクラス B が新しい関数 P2 を完成すると、以下に示すように、元の関数 P1 が誤動作する可能性があります。

CountPriceByJKL クラスは CountPrice クラスを継承し、Count() メソッドをオーバーライドします。これは、元の Count メソッドの機能に影響を与える可能性があります。

修正: 継承を使用する場合は、Liskov 置換原則に従います。クラス B がクラス A を継承する場合、新しい関数 P2 を完成させるために新しいメソッドを追加する場合を除き、親クラス A のメソッドをオーバーライドしたり、親クラス A のメソッドをオーバーロードしたりしないようにしてください。

3. 依存関係逆転の原理

定義: 高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方ともその抽象化に依存すべきであり、抽象化は詳細に依存すべきではなく、抽象化に依存すべきです。

これは最も理解しにくいものです。たとえば、ビジネス ロジック層はデータ層を呼び出す必要があるため、ビジネス ロジック層はデータ層に比べて上位のモジュールです。スケーラビリティと高い再利用性を実現するには、ビジネス ロジック層がデータ層に依存しないようにする必要があります。データ層でインターフェイスを抽象化し、ビジネス ロジック層がこの抽象に依存するようにすることができます。インターフェース。

シナリオ: クラス A (高レベル モジュール) がクラス B (低レベル モジュール) に直接依存するように変更する場合は、クラス A のコードを変更する必要があります。 。このシナリオでは、通常、クラス A は複雑なビジネス ロジックを担当する高レベル モジュールであり、クラス B と C は基本的なアトミック操作を担当する低レベル モジュールです。クラス A が変更されると、プログラムに不要なリスクが生じます。

AutoSystem クラスは HondaCar クラスと FordCar クラスに直接依存しているため、高度な結合が作成されます。AutoSystem クラスが HondaCar または FordCar を制御したい場合は、対応するオブジェクトを直接作成する必要があります。

変更: インターフェイス I に依存するようにクラス A を変更します。クラス B とクラス C はそれぞれインターフェイス I を実装します。クラス A は、インターフェイス I を通じて間接的にクラス B またはクラス C に接続します。これにより、以下に示すように、クラス A が変更される可能性が大幅に減少します。

この変更後、ホンダとフォードは ICar インターフェイスを実装し、Run、Stop、Turn 関数メソッドを提供しました。これにより、AutoSystem は抽象インターフェイスに依存することになり、AutoSystem クラスがより多くの要件の変更に対応できるようになります。 。

利点:

1) 低レベルのモジュールには、抽象クラスまたはインターフェイス、あるいはその両方が必要です。

2) 変数の宣言型は、可能な限り抽象クラスまたはインターフェースにする必要があります。

3) 継承を使用する場合は、リスコフ置換原則に従います。

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

定義: クライアントは、必要のないインターフェイスに依存すべきではありません。あるクラスの別のクラスへの依存は、最小のインターフェイスに基づく必要があります。

シナリオ: クラス A はインターフェイス I を通じてクラス B に依存し、クラス C はインターフェイス I を通じてクラス D に依存します。インターフェイス I がクラス A とクラス B の最小インターフェイスではない場合、クラス B とクラス D は、それらが行うメソッドを実装する必要があります。以下に示すように、必要ありません。

修正: 肥大化したインターフェース I をいくつかの独立したインターフェースに分割し、クラス A とクラス C がそれぞれ必要なインターフェースとの依存関係を確立します。つまり、インターフェース分離の原理が採用されています。

注意:

1) インターフェースは可能な限り小さくする必要がありますが、制限内にします。インターフェースを改良するとプログラミングの柔軟性が向上するのは事実ですが、小さすぎるとインターフェースが多くなり、設計が複雑になります。したがって、それは適度に行う必要があります。

2) インターフェイスに依存するクラスのサービスをカスタマイズし、必要なメソッドのみを呼び出しクラスに公開し、必要のないメソッドを非表示にします。モジュールにカスタマイズされたサービスを提供することに重点を置くことによってのみ、確立される依存関係を最小限に抑えることができます。

3) 結束力を向上させ、外部との相互作用を軽減します。ほとんどのことを達成するためにインターフェイスで使用するメソッドを最小限にします。

5. デメテルの法則（あまり知られていない原理）

定義: オブジェクトは他のオブジェクトについての最小限の知識を保持する必要があります。

シナリオ: クラス間の関係が緊密であればあるほど、一方のクラスが変更されると、他方のクラスへの影響が大きくなります。

シンプルな理解は凝集性が高い クラスのメソッドと属性をプライベートにできる場合は、できるだけプライベートにするようにしてください。

注意:

1) 直接の友人とのみ通信し、見知らぬ人と話さないでください。

2) この原則を過度に使用すると、システムの複雑さが増加します。したがって、ディミットの法則を採用する場合は、明確な構造と高い凝集性と低い結合性の両方を達成するために、トレードオフを繰り返し検討する必要があります。

6.開閉原則

定義: クラス、モジュール、関数などのソフトウェア エンティティは、拡張のためにオープンし、変更のためにクローズする必要があります。

シナリオ: ソフトウェアのライフサイクル中に、変更、アップグレード、メンテナンスなどによりソフトウェアの元のコードを修正する必要がある場合、古いコードにエラーが導入されたり、コード全体を再構築する必要がある場合があります。そして、元のコードを再テストする必要があります。

推奨事項: ソフトウェア要件が変更された場合は、既存のコードを変更するのではなく、ソフトウェア エンティティの動作を拡張することによって変更を実現するようにしてください。

http://www.bkjia.com/PHPjc/980917.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/980917.html技術記事 PHP 設計パターン - 6 つの原則 一般に、次の 6 つの原則に従うコードは拡張し、再利用可能であると考えられています。これらの 6 つの原則は、オブジェクト指向言語でも従う必要があります...

。