ファクトリメソッドパターン

工場や組立ラインでは、作業が何度も繰り返されるので、私たちプログラマーよりも本当に大変です。

ファクトリ パターンも非常に頻繁に使用されます。その公式の説明は、オブジェクトを作成するためのインターフェイスを定義し、どのクラスをインスタンス化するかをサブクラスに決定させるというものです。ファクトリ パターンは、クラスのインスタンス化をそのサブクラスに延期します。

図に示すように、システムにはスーパー ユーザーと一般ユーザーの 2 種類があり、パブリック インターフェイス User クラスを定義し、userFactory クラスに createUser メソッドを実装して作成します。 abstractUserFactory クラスを継承して User クラスを作成し、それによってファクトリー モードを実現する実装コードは次のとおりです:

Php コード

<?php  
abstract class abstractUserFactory {  
    public abstract function createUser();  
}  
  
class userFactory extends <span style="font-size: 1em; line-height: 1.5;">abstractUserFactory </span><span style="font-size: 1em; line-height: 1.5;">{</span>  
Php代码  
    public function createUser( $className ) {  
        try{  
            if(class_exists($className))  
                return new $className();  
            else{  
                $error = "no class";  
                throw new Exception($error);  
            }  
        }catch( Exception $e ) {  
            echo &#39;Caught exception: &#39;,  $e->getMessage(), "\n";  
        }  
    }  
}  
  
  
interface User{  
    public function getGrade();  
}  
  
class superUser implements User{  
    public function getGrade() {  
        echo 1;  
    }  
}  
  
class commonUser implements User{  
    public function getGrade() {  
        echo 0;  
    }  
}  
  
$userFactory = new userFactory();  
$userFactory->createUser( &#39;superUser&#39; )->getGrade();  
$userFactory->createUser( &#39;commonUser&#39; )->getGrade();  
  
运行结果：10Caught exception: no class

ファクトリー モードの利点:

1. 優れたカプセル化と明確なコード構造。たとえば、呼び出し元が特定の製品オブジェクトを必要とする場合、その製品のクラス名 (または制約文字列) を知るだけで済みます。オブジェクトを作成するという面倒なプロセスを知る必要はありません。これにより、モジュール間の結合が軽減されます。

2. 非常に優れた拡張性。製品カテゴリを追加する場合、特定のファクトリ クラスを適切に変更するか、ファクトリ クラスを拡張する限り、「変更の受け入れ」を完了できます。たとえば、上記の例では、青いひし形のユーザーを追加する必要がある場合、ファクトリ クラスを追加するだけで、タスクを変更せずにシステムの拡張を完了できます。

3. シールド製品カテゴリ。この機能は非常に重要です。呼び出し元は、製品クラスの実装がどのように変更されるかを気にする必要はありません。製品のインターフェイスが変更されない限り、システム内の上位モジュールは気にする必要があります。変わらない。

4. 典型的なデカップリングフレームワーク。上位モジュールの値は製品の抽象クラスを知る必要があり、他の実装クラスは気にする必要はありません。必要がなければ通信する必要はありません。これは、製品クラスの抽象化のみに依存する依存性逆転の原則にも準拠しています。もちろん、置換原則に従って、製品の親クラスを置き換えるのに製品のサブクラスを使用します。問題ありません。

ファクトリ パターンの使用シナリオ:

1. ファクトリ パターンは新しいオブジェクトの置き換えであるため、オブジェクトを生成する必要がある場合はどこでも使用できますが、管理用のファクトリ クラスを追加してコードを追加するかどうかを慎重に検討する必要があります。複雑。

2. 柔軟でスケーラブルなフレームワークが必要な場合は、ファクトリ パターンの使用を検討できます。すべては物体であり、すべては製品です。

3. ファクトリ パターンは異種プロジェクトで使用できます。

4. テスト駆動開発フレームワークを使用できます。たとえば、クラス A をテストするには、クラス A に関連するクラス B を同時に生成する必要があります。ファクトリ パターンを使用してクラス B を仮想化し、クラス A とクラス B 間の結合を回避できます。 (現在、Java には jmock と easymock があり、このシナリオは弱められています)。

ファクトリ パターンの拡張:

1. 単純なファクトリ パターン (PHP でよく使用されます)

モジュールにはファクトリ クラスのみが必要で、生成する必要はなく、静的メソッドを使用するだけです。この要件に基づいて、図に示すように、上の例の abstractUserFactory を変更します。

abstractUserFactory 抽象クラスを削除し、createUser を静的クラスに設定します。これにより、クラス作成プロセスが簡素化されます。欠点は、ファクトリ クラスの拡張が難しく、開閉原則に準拠していないことですが、それでも非常に実用的なデザイン パターンです。

2. 複数のファクトリ クラスへのアップグレード (製品とファクトリの間で 1 対 1)

各製品クラスが作成クラスに対応する利点は、作成クラスの責任が明確であり、構造が単純であることです。 、しかし、それは拡張性を提供し、保守性は一定の影響を与えます。製品クラスを拡張したい場合は、対応するファクトリ クラスを作成する必要があるため、拡張の難易度が高くなります。ファクトリ クラスと製品の数は同じであるため、メンテナンス時に 2 つのオブジェクト間の関係を考慮する必要があります。

もちろん、複雑なアプリケーションでは、通常、マルチファクトリ メソッドが使用され、その後、呼び出し元が各サブファクトリと通信するのを防ぐために調整クラスが追加されます。調整クラスの機能は、サブファクトリをカプセル化することです。クラスを統合し、高レベルのモジュールへの統合アクセス インターフェイスを提供します。

3. シングルトン モードの代替

このモードは、リフレクションを通じてプライベートな引数なしのコンストラクターを定義するクラスをインスタンス化することによって実装されます。 PHP では目視検査はできないので、ここでは省略します。

4. 遅延初期化

オブジェクトが消費された後、ファクトリ クラスは初期状態を維持し、再度使用されるのを待ちます。 PHP インタープリタ言語の場合、これを遅延ロードに拡張できます。つまり、スクリプトが実行されるたびに可能なクラスをロードするのではなく、ファクトリ クラスが新しいオブジェクトを作成する準備ができたときにのみ、対応するクラス ファイルがロードされます。