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

声明: この一連のブログの参考資料は、Cheng Jie 著の「Dahua Design Pattern」です。

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

具体的なケース: MM をマクドナルドに誘い、それぞれの好みを覚えておくのは面倒です。通常、FactoryMethod モデルを使用して、MM をウェイターに連れて行き、「ハンバーガーが食べたいです。」 「どんなハンバーガーが食べたいかは、女の子に直接ウェイターに伝えてください。

コア ファクトリ クラスは、すべての製品の作成を担当しなくなりましたが、特定の作成作業はサブクラスに任せ、抽象ファクトリの役割となり、特定のファクトリ クラスが実装する必要があるインターフェイスを提供することのみを担当します。以下の図に示すように、どのプロダクト クラスをインスタンス化するかについての詳細:

ファクトリ メソッド パターンは主に次の役割で構成されます:

use using using ' s ' s 's ‐ ‐ ‐プログラムはそれとは何の関係もありません。パターンで作成されたオブジェクトのファクトリ クラスはすべて、このインターフェイスを実装する必要があります。

具象ファクトリ ロール (ChickenLegBaoFactory): 抽象ファクトリ インターフェイスを実装する具象ファクトリ クラスであり、アプリケーションに密接に関連するロジックが含まれており、製品オブジェクトを作成するためにアプリケーションによって呼び出されます。
abstract製品ロール（Ihanbao）：Factoryメソッドパターンによって作成されたオブジェクトのスーパータイプ。これは、製品オブジェクトの一般的な親クラスまたは一般的に所有されているインターフェイスです。上の写真では、このキャラクターはライトです。

特定の製品ロール (ChickenLegBao): このロールは、抽象製品ロールによって定義されたインターフェイスを実装します。特定の製品は特定の工場で作られ、それらの間には 1 対 1 の対応関係があることがよくあります。 hower上記のUMLクラス図と役割に基づいて、次のPHPコードを書きます。

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

長所: 単純なファクトリ パターンのオープン-クローズ原則の違反を克服し、オブジェクト作成プロセスをカプセル化する利点を維持します。当 ： 欠点：製品を追加する場合、製品工場のクラスを上げ、追加の開発量を増やす必要があります。分岐判断の問題は避けて通れません。

シンプルファクトリーパターンとファクトリーメソッドパターンの比較:

1. 構造の複雑さ

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

2. コードの複雑さ

シンプル ファクトリ パターンのファクトリ クラスは、製品カテゴリが増加するにつれて多くのメソッド (またはコード) を追加する必要がありますが、ファクトリ メソッド パターンでは、特定の各ファクトリ クラスは 1 つのタスクのみを完了し、コードは簡潔です。 上 3. 管理の難しさ

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

PHP オブジェクト指向デザイン パターン