PHP実装デザインパターンにおける抽象ファクトリパターンの詳細説明、デザインパターンの詳細説明_PHPチュートリアル
- WBOYオリジナル
- 2016-07-13 10:17:29817ブラウズ
PHP実装デザインパターンにおける抽象ファクトリーパターンの詳細説明、デザインパターンの詳細説明
Abstract Factory パターン (Abstract Factory) は、一般的なソフトウェア設計パターンです。このパターンは、製品ファミリーに統一された作成インターフェイスを提供します。この製品ファミリーの特定のシリーズが必要な場合、この製品ファミリーのシリーズに対して特定のファクトリ クラスを作成できます。
【意図】
抽象ファクトリ パターンは、特定のクラスを指定せずにシステム関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します [GOF95]
【抽象的な工場パターン構造図】
【抽象ファクトリーパターンの主役】
Abstract Factory ロール: 抽象製品オブジェクトを作成するためのインターフェイスを宣言します。通常、インターフェイスまたは抽象クラスとして実装され、すべての具象ファクトリ クラスはこのインターフェイスを実装するか、このクラスを継承する必要があります。
Concrete Factory ロール: 製品オブジェクトを作成する操作を実装します。クライアントはこのロールを直接呼び出して、製品のインスタンスを作成します。このロールには、適切な製品オブジェクトを選択するためのロジックが含まれています。通常は具象クラスを使用して実装されます。
抽象的な製品の役割: 製品の種類のインターフェイスを宣言します。これは、ファクトリ メソッド パターンによって作成されたオブジェクトの親クラス、またはそれらが共有するインターフェイスです。
具体的な製品ロール: 抽象的な製品ロールによって定義されたインターフェイスを実装し、対応する具体的なファクトリによって作成される製品オブジェクトを定義します。アプリケーションのビジネス ロジックが含まれています。
【抽象ファクトリーパターンのメリットとデメリット】
抽象ファクトリー パターンの利点:
1. 特定のクラスを分離する
2. 製品ファミリーの追加または置換を簡単にします
3. 製品の一貫性を保つ
抽象ファクトリー パターンの欠点: 新しいタイプの製品をサポートするのが困難です。これは、AbstractFactory インターフェイスによって、作成できる製品のコレクションが決定されるためです。新しいタイプの製品をサポートするには、ファクトリ アクセス インターフェイスを拡張する必要があり、その結果、AbstractFactory クラスとそのすべてのサブクラスが変更されます。
抽象ファクトリーは、新しい製品の追加を斜めの方法でサポートしますが、新しい製品ファミリーの追加には利便性を提供しますが、新しい製品の階層構造の追加にはそのような利便性を提供できません。
【抽象ファクトリーパターンの適用シナリオ】
抽象ファクトリー パターンは次の状況で使用する必要があります:
1. システムは、製品クラスのインスタンスがどのように作成、結合、表現されるかという詳細に依存すべきではありません。これは、あらゆる形式のファクトリー パターンにとって重要です。
2. このシステムの製品には複数の製品ファミリーがあり、システムはそのうちの 1 つのファミリーの製品のみを消費します。
3. 同じ製品ファミリに属する製品を併用するため、この制約をシステム設計に反映する必要があります。
4. システムは製品ライブラリを提供し、すべての製品が同じインターフェイスで表示されるため、クライアントの使用は実装に依存しません
[Java とパターン ページ 189]
Abstract Factory モードのいくつかの重要なポイント:
1. 「多系列オブジェクト構築」の需要変化に対応する必要がない場合は、Abstract Factory モードを使用する必要はありません。
2. 「シリーズ オブジェクト」とは、オブジェクト間の相互依存または相互作用を指します。
3. Abstract Factory モデルは、主に「新シリーズ」の需要の変化に対応するように設計されています。デメリットは対処が難しいこと
「新しいもの」に対する需要の変化。前述したように、今すぐ参加したい場合は、これに注意してください
他のシリーズのクラスの場合、コードの変更は大幅に行われます。
4. Abstract Factory モードは、多くの場合、それに対処するために Factory Method モードと組み合わせられます
「オブジェクトの作成」の要件の変更。
抽象ファクトリーに追加されました
1. 製品階層構造の数が変わらない場合、新しい製品ファミリーを追加することは、各製品階層構造に 1 つ (または複数) の新しい具体的 (または抽象的および具象的) 製品の役割を追加することを意味します。 工場レベルの構造は、製品レベルの構造と並行する登録組織であるため、製品レベルの構造が調整されると、それに応じて工場レベルの構造も調整する必要があります。新しい要素が製品階層に現れたので、対応する新しい要素を工場階層に追加する必要があります。 つまり、設計者は新しい特定のファクトリ クラスをシステムに追加するだけで済み、既存のファクトリ ロールや製品ロールを変更する必要はありません。したがって、システム内の製品ファミリーが増加すると、抽象ファクトリー パターンは「オープン-クローズ」原則をサポートします。
2. 製品ファミリーの数は変更せずに、新しい製品レベル構造を追加します。つまり、すべての製品クラスの製品数は変わりませんが、既存の製品クラスと並行して新しい製品クラスが存在します。 これを行うには、すべてのファクトリ ロールを変更し、各ファクトリ クラスに新しいファクトリ メソッドを追加する必要があります。これは明らかに「オープン-クローズ」原則に違反します。言い換えれば、製品の階層構造が増加するため、抽象的な工場パターンは「開閉」原則をサポートしません。
まとめると、既存の抽象積に具体積を追加することは「オープン-クローズの原則」をサポートしますが、抽象積を追加することは「オープン-クローズ」の原則をサポートしないことがわかります。抽象ファクトリー パターンは、新しい製品の追加を斜めにサポートしますが、新しい製品ファミリーの追加には利便性を提供しますが、新しい製品の階層構造の追加にはそのような利便性を提供できません。
【抽象的な工場パターンとその他のパターン】
シングルトン モード: 特定のファクトリ クラスをシングルトン クラスとして設計できるため、通常は 1 つのファクトリで十分であるため、特定のファクトリ サブクラスは通常シングルトンとして実装されます。
ファクトリメソッドパターン(ファクトリメソッドパターン): 抽象的なファクトリで製品を作成するメソッドがファクトリメソッドとして定義されます。
試作モード: 複数の製品シリーズが考えられる場合、特定の工場でも試作モードを使用でき、特定の工場が製品シリーズを使用します。
各製品のプロトタイプがインスタンス化され、そのプロトタイプをコピーすることで新しい製品が作成されます。
【抽象ファクトリーパターンPHPサンプル】
/**
* 抽象的な工場パターン 2010-05-28 sz
* @author phppan.p#gmail.com
*@パッケージデザインパターン
*/
/**
*抽象ファクトリー
*/
インターフェイス AbstractFactory {
/**
* * 階層構造を持つプロダクトを作成するファクトリメソッド A
*/
パブリック関数 createProductA();
/**
* * 階層構造を持つプロダクトを作成するファクトリメソッド B
*/
パブリック関数 createProductB();
}
/**
※特定工場1
*/
クラス ConcreteFactory1 は AbstractFactory{
を実装します
パブリック関数 createProductA() {
新しい ProductA1() を返します;
}
パブリック関数 createProductB() {
新しい ProductB1() を返します;
}
}
/**
※特定工場2
*/
クラス ConcreteFactory2 は AbstractFactory{
を実装します
パブリック関数 createProductA() {
新しい ProductA2() を返します;
}
パブリック関数 createProductB() {
新しい ProductB2() を返します;
}
}
/**
*抽象的な製品 A
*/
インターフェイス AbstractProductA {
/**
* 製品名を取得します
*/
パブリック関数 getName();
}
/**
*抽象的な製品 B
*/
インターフェイス AbstractProductB {
/**
* 製品名を取得します
*/
パブリック関数 getName();
}
/**
※特定商品Ａ1
*/
クラス ProductA1 は AbstractProductA を実装します {
プライベート $_name;
パブリック関数 __construct() {
$this->_name = '製品 A1';
}
パブリック関数 getName() {
$this->_name を返す;
}
}
/**
※特定商品Ａ２
*/
クラス ProductA2 は AbstractProductA を実装します {
プライベート $_name;
パブリック関数 __construct() {
$this->_name = '製品 A2';
}
パブリック関数 getName() {
$this->_name を返す;
}
}
/**
*特定の製品B1
*/
クラス ProductB1 は AbstractProductB を実装します {
プライベート $_name;
パブリック関数 __construct() {
$this->_name = '製品 B1';
}
パブリック関数 getName() {
$this->_name を返す;
}
}
/**
*特定の製品B2
*/
クラス ProductB2 は AbstractProductB を実装します {
プライベート $_name;
パブリック関数 __construct() {
$this->_name = '製品 B2';
}
パブリック関数 getName() {
$this->_name を返す;
}
}
/**
*クライアント
*/
クラスクライアント {
/**
* メインプログラム
*/
パブリック静的関数 main() {
self::run(new ConcreteFactory1());
self::run(new ConcreteFactory2());
}
/**
* ファクトリインスタンスを呼び出してプロダクトを生成し、プロダクト名を出力します
* @param $factory AbstractFactory ファクトリ インスタンス
*/
パブリック静的関数 run(AbstractFactory $factory) {
$productA = $factory->createProductA();
$productB = $factory->createProductB();
echo $productA->getName(), '
';
echo $productB->getName(), '
';
}
}
クライアント::メイン();
?>
ファクトリ メソッド パターン:
抽象プロダクト クラスは、複数の特定のプロダクト クラスを派生できます。
抽象ファクトリ クラスは、複数の具象ファクトリ クラスを派生できます。
各具象ファクトリ クラスは、特定の製品クラスのインスタンスを 1 つだけ作成できます。
抽象ファクトリ パターン:
複数の抽象製品クラス。各抽象製品クラスは複数の特定の製品クラスを派生できます。
抽象ファクトリ クラスは、複数の具象ファクトリ クラスを派生できます。
各具体的なファクトリ クラスは、特定の製品クラスの複数のインスタンスを作成できます。
違い:
ファクトリ メソッド パターンには抽象製品クラスが 1 つだけありますが、抽象ファクトリ パターンには複数の抽象製品クラスがあります。
ファクトリ メソッド パターンの具象ファクトリ クラスは、特定の製品クラスのインスタンスを 1 つだけ作成できますが、抽象ファクトリ パターンは複数のインスタンスを作成できます。
Abstract Factory: ファクトリ パターンよりも 1 つ深いレベルであり、ファクトリの実装クラスさえも不明です。人によって異なるファクトリ クラスを取得できます。したがって、抽象ファクトリ クラスは実際には、さまざまなファクトリ クラスを生成できるファクトリ クラスです。
簡単に言うと、「ファクトリでオブジェクトを生成する」という関係を第1レベルの世代関係とすると、抽象ファクトリメソッドは第2レベルの世代関係を持つファクトリメソッドになります。実際の環境がより複雑な場合は、レベル 3 またはレベル 4 になる可能性もあります。非常に単純なので、あまり複雑に考える必要はありません。
デザイン パターンに関するこの本はよく書かれていますが、インスピレーションのために読んでください。深く掘り下げないでください。理由は次のとおりです。
デザイン パターンが以前に書かれたとき、プログラマーのプログラムの理解は、コードがコンパイルされて渡されることができれば十分でした。今ではばかげていると思われる機能がたくさんあります。言うまでもなく、これは工業化時代の石器時代の製品を見ているためです。 Java 言語用なので、一部の機能はまったく使用できません
実際の作業で遭遇する状況は、デザイン パターンで説明されているものよりもはるかに単純です。まったく使えないのは馬鹿げているので、詳しく調べる必要はありません
この本が一番です。一番良い方法は、読み飛ばすのではなく、根気よく読むことです。トラブルに巻き込まれても、普通に読んで、止まらないでください。これを読んだ後はそれほどすごい人にはなれませんが、今後数年間の開発作業で理解できていないことがたくさんあることを振り返ってみると、自然と明らかになるでしょう。時々、コード作成プロセスについて質問したり、インスピレーションを得たりします。