2

ファクトリパターンの特定の側面を明るくします。
ファクトリメソッドを使用するのはいつですか？

私のチームでは、ファクトリデザインパターンについての議論がありました。

私たちのプロジェクトには、次のように構築されたいくつかのファクトリがあります。

class ProductFactory {

    const PRODUCT_A = 'product_a';
    const PRODUCT_B = 'product_b';
    const PRODUCT_C = 'product_c';

    private static $classMapping = array(self::PRODUCT_A => 'A',
                                         self::PRODUCT_B => 'B',
                                         self::PRODUCT_C => 'C');

    public function create($productConstant) {
        $className = self::$classMapping[$productConstant];
        return new $className();
    }
}

議論はこの工場の使用についてでした。製品を動的に定義せず、常に製品から受け取りたい製品を定義する場合、このパターンを使用する必要はありますか？

4

2 に答える 2

2

ファクトリの利点は、コードを分離することです。Foo次のインスタンスが必要なクラスを取得しますA。

class Foo {

    public function __construct() {
        $a = new A;
    }

}

このクラスFooは、ソースにクラス名をハードコードしているため、クラスに結合されてAいます。たとえば、テストをモックインする場合など、 Atoの代替実装を提供することはできません。ここに工場があります：FooA

class Foo {

    public function __construct(ProductFactory $factory) {
        $a = $factory->create($factory::PRODUCT_A);
    }

}

これで、必要に応じて任意の種類のを注入できAます。これで、2つのクラスが分離されました。Foo

それが工場の目的です。必要に応じて使用してください。Fooとの結合に問題がない場合はA、より多くの電力を使用できます。

于 2012-10-26T13:06:45.033 に答える
1

場合によります。

デザインパターンは、問題を作成するためではなく、問題を解決するためにあります。

  • 別のクラス内で製品を作成する場合、ファクトリはテスト用のモックオブジェクトを提供できます。
  • コンストラクターとは異なる種類のデータを使用して製品を作成する場合は、ファクトリが役立ちます。
  • 依存性注入を厳密に使用する場合は、ファクトリは必要ありません
  • 工場の本当の理由がない場合は、それを使用しないでください。
于 2012-10-26T13:03:20.993 に答える