PHP デザイン パターン - Factory Method_PHP チュートリアル

PHP デザインパターン - ファクトリメソッド

先ほど簡単なファクトリーを紹介しましたが、今日は引き続き別のファクトリー-ファクトリーメソッドを学習します。

特定のケース: MM にハンバーガーを食べに行くよう頼む。MM によって味が異なる。通常、FactoryMethod モードを使用して、MM をウェイターに連れて行き、「ハンバーガーが食べたい」と言うのは面倒です。どの種類のバーガーが欲しいか、MM にウェイターに直接伝えるように頼んでください。

ファクトリ メソッド パターン コア ファクトリ クラスは、すべての製品の作成を担当しなくなり、特定の作成作業をサブクラスに任せ、特定のファクトリ クラスが実装する必要があるインターフェイスを提供することのみを担当します。以下に示すように、製品クラスはこの詳細でインスタンス化される必要があります:


ファクトリーモードモードは主に次の役割で構成されます:

抽象ファクトリ ロール (IServerFactory): ファクトリ メソッド パターンの中核であり、アプリケーションとは何の関係もありません。パターンで作成されたオブジェクトのファクトリ クラスはすべて、このインターフェイスを実装する必要があります。

具象ファクトリ ロール (ChickenLegBaoFactory): これは、抽象ファクトリ インターフェイスを実装する具象ファクトリ クラスで、アプリケーションに密接に関連するロジックが含まれており、製品オブジェクトを作成するためにアプリケーションによって呼び出されます。

抽象製品ロール (IHanbao): ファクトリ メソッド パターンによって作成されるオブジェクトのスーパー タイプ。製品オブジェクトの共通の親クラスまたは共通に所有されるインターフェイスです。上の写真では、このキャラクターはライトです。

具体的な製品ロール (ChickenLegBao): このロールは、抽象的な製品ロールによって定義されたインターフェイスを実装します。特定の製品は特定の工場で作られ、それらの間には 1 対 1 の対応関係があることがよくあります。

上記の UML クラス図と役割に基づいて、次の PHP コードを作成します。

リーリー

テストコード:

リーリー

ブラウザでテスト コードを実行すると、顧客全員が食事を楽しんでいることがわかります。

ファクトリメソッドパターンの長所と短所:

利点: 単純なファクトリ モデルの開閉原則の違反を克服し、オブジェクト作成プロセスをカプセル化する利点を維持します。

欠点: 製品を追加する場合、製品ファクトリ クラスを追加する必要があるため、追加の開発量が増加します。分岐判断の問題は避けて通れません。

単純なファクトリ パターンとファクトリ メソッド パターンの比較:

1. 構造の複雑さ

シンプルなファクトリーモデルが普及するでしょう。単純なファクトリ パターンではファクトリ クラスが 1 つだけ必要ですが、ファクトリ メソッド パターンのファクトリ クラスはプロダクト クラスの数が増えるにつれて増加するため、構造が複雑になります。

2. コードの複雑さ

コードの複雑さと構造の複雑さは矛盾しています。単純なファクトリ パターンは構造の点では比較的単純であるため、コードの点ではファクトリ メソッド パターンよりも複雑でなければなりません。シンプル ファクトリ パターンのファクトリ クラスは、プロダクト クラスが増加するにつれて多くのメソッド (またはコード) を追加する必要がありますが、ファクトリ メソッド パターンでは、特定の各ファクトリ クラスは 1 つのタスクのみを完了し、コードは簡潔です。

3. 管理の難しさ

特定の製品カテゴリを変更する必要がある場合は、対応するファクトリ クラスも変更する必要がある可能性があります。複数のプロダクトクラスを同時に変更する必要がある場合、ファクトリクラスを変更するのは非常に面倒になります。逆に、単純なファクトリでは、複数の製品クラスを変更する必要がある場合でも、単一のファクトリ クラスを変更するだけで済みます。