ホームページ バックエンド開発 PHPチュートリアル デザインパターンの6つの原則の詳細な紹介

デザインパターンの6つの原則の詳細な紹介

Mar 15, 2017 pm 05:13 PM

単一責任の原則

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


リヒター置換原理

定義 1: T1 型のすべてのオブジェクト o1 に対して、T2 型のオブジェクト o2 が存在する場合、T1 で定義されたすべてのプログラム P は、When allオブジェクト o1

が o2 に置き換えられると、プログラム P の動作は変わりません。その場合、型 T2 は型 T1 のサブタイプになります。

定義 2: 基本クラスを参照するすべての場所で、そのサブクラスのオブジェクトを透過的に使用できなければなりません。言い換えれば、基本クラスが出現できる場所には必ずサブクラスが出現する可能性があります


平たく言えば、リヒター置換原理とは、サブクラスは親クラスの機能を拡張できますが、親クラスの元の機能を変更することはできないことを意味します。これには次の 4 つのレベルの意味が含まれます:

1) サブクラスは親クラスの抽象メソッドを実装できますが、親クラスの非抽象メソッドをオーバーライドすることはできません。

2) サブクラスは独自のメソッドを追加できます。

3) サブクラスの メソッドが親クラスのメソッドをオーバーライドする場合、メソッドの前提条件 (つまり、メソッドの仮パラメータ) は、親クラスのメソッドの入力パラメータよりも緩くなります。

4) サブクラスのメソッドが親クラスの抽象メソッドを実装する場合、メソッドの事後条件 (つまり、メソッドの戻り値) は親クラスの事後条件よりも厳しくなります。



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

依存関係逆転の原理の核となる考え方は、インターフェース

のためのプログラミングです。

依存関係を転送するには、1.インターフェースの転送、2.コンストラクターメソッド
の転送、3.セッターメソッドの転送の3つの方法があります。

実際のプログラミングでは、通常、次の 3 つの点を行う必要があります:

1) 低レベルのモジュールには、抽象クラス
、またはその両方が必要です。

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

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


インターフェース分離原則

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

大規模な全体的なインターフェイスを提供するのではなく、できる限り小さい個々のインターフェイスをクライアントに提供する必要があります。

1) 単一の一般的なインターフェイスよりも、複数の特殊なインターフェイスを使用する方が優れています。

2) あるクラスの別のクラスへの依存は、最小のインターフェイスに基づく必要があります。

3) インターフェイスはロールを表し、異なるロールを 1 つのインターフェイスに割り当てないでください。関係のないインターフェイスが結合されて、大きく肥大化したインターフェイスが形成され、ロールとインターフェイスが汚染されます。

4) 「クライアントは、使用していないメソッドに依存することを強制されるべきではありません。インターフェイスは、それが配置されているクラス階層ではなく、クライアントに属します。」これは明らかであり、より一般的に言えますが、顧客が使用していない方法の使用を強制しないでください。ユーザーに使用しない方法の使用を強制すると、これらの方法の変更によって顧客は変化に直面することになります。彼らは使いません。


Demit Principle

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

明らかに、インターフェイス分離原則と一般化された Dimit 原則は、1 つのソフトウェア エンティティと他のソフトウェア エンティティの間の通信に対する制限です。一般化されたデメテル原則では、

はコミュニケーションの幅と深さを可能な限り制限する必要があります。インターフェイス分離の原則によって制限されるのは通信の幅です。つまり、通信は可能な限り狭くする必要があります。

デメテルの法則は、最も知られていない原理とも呼ばれ、1987年に米国のノースイースタン大学のイアン・ホランドによって初めて提案されました。平たく言えば、クラスが依存するクラスについての知識が少ないほど良いことを意味します。つまり、依存するクラスは、どんなに複雑なロジックであっても、ロジック

を可能な限りクラス内にカプセル化し、提供されるpublicメソッド以外には情報が外部に漏洩しないようにする。デメテルの法則にはもっと簡単な定義があります: 直接

している友達とのみ通信する。まず、直接のフレンドとは何かについて説明します。各オブジェクトは他のオブジェクトとカップリング関係を持ちます。2 つのオブジェクト間にカップリング関係がある限り、その 2 つのオブジェクトはフレンドであると言われます。結合には、依存関係、関連付け、結合、集約など、さまざまな方法があります。このうち、メンバー変数、メソッドのパラメータ、メソッドの戻り値に現れるクラスを直接の友達と呼びますが、ローカル変数に現れるクラスは直接の友達ではありません。言い換えれば、馴染みのないクラスがローカル変数としてクラス内に出現しないことが最善です。

オープンとクローズの原則

ソフトウェアエンティティは、拡張に対してオープンであり、変更に対してクローズである必要があります。


組み合わせ/集合再利用の原則

再利用の目的を達成するには、継承関係の代わりに組み合わせ/集合を使用するようにしてください。


以上がデザインパターンの6つの原則の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットな記事タグ

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

Java フレームワークにおけるデザイン パターンとアーキテクチャ パターンの違い Java フレームワークにおけるデザイン パターンとアーキテクチャ パターンの違い Jun 02, 2024 pm 12:59 PM

Java フレームワークにおけるデザイン パターンとアーキテクチャ パターンの違い

Java 設計パターンにおけるアダプター パターンの素晴らしい使用法 Java 設計パターンにおけるアダプター パターンの素晴らしい使用法 May 09, 2024 pm 12:54 PM

Java 設計パターンにおけるアダプター パターンの素晴らしい使用法

Java デザイン パターンにおけるデコレータ パターンの分析 Java デザイン パターンにおけるデコレータ パターンの分析 May 09, 2024 pm 03:12 PM

Java デザイン パターンにおけるデコレータ パターンの分析

PHP設計パターンの実践事例分析 PHP設計パターンの実践事例分析 May 08, 2024 am 08:09 AM

PHP設計パターンの実践事例分析

Java フレームワークでデザイン パターンを使用する利点と欠点は何ですか? Java フレームワークでデザイン パターンを使用する利点と欠点は何ですか? Jun 01, 2024 pm 02:13 PM

Java フレームワークでデザイン パターンを使用する利点と欠点は何ですか?

Guice フレームワークでのデザイン パターンの適用 Guice フレームワークでのデザイン パターンの適用 Jun 02, 2024 pm 10:49 PM

Guice フレームワークでのデザイン パターンの適用

デザインパターンがコードメンテナンスの課題にどのように対処するか デザインパターンがコードメンテナンスの課題にどのように対処するか May 09, 2024 pm 12:45 PM

デザインパターンがコードメンテナンスの課題にどのように対処するか

PHP デザイン パターン: テスト駆動開発の実践 PHP デザイン パターン: テスト駆動開発の実践 Jun 03, 2024 pm 02:14 PM

PHP デザイン パターン: テスト駆動開発の実践

See all articles