web-dev-qa-db-ja.com

工場パターンおよび/または依存性注入？

私はその概念を理解しており、ファクトリーパターンと依存性注入の両方を使用できますが、概念的には少し矛盾しています。どちらを使うのですか？または、それらを互いに組み合わせて使用​​できますか？

DIを使用する場合、ファクトリ内のクラスの作成をハードコーディングしますか？これはDIのポイントを無効にしませんか？ファクトリは、作成するクラスの存在に依存しているため、DIを使用する場合、実行時にファクトリに渡す必要があります。

または、ファクトリが作成することを意図しているクラスを、ファクトリが作成することを意図しているクラスに渡しますか？もしそうなら、それは最初に工場を建設するという点を打ち負かさないでしょうか？インジェクターが基本的に工場のすべての仕事をしているので。

ご静聴ありがとうございました。

design-patternsobject-orienteddependency-injection
12
Samuel Hawksby-Robinson

DIを使用する場合、ファクトリ内でのクラスの作成をハードコーディングしますか？これはDIのポイントを無効にしませんか？

いいえ、ファクトリの目的は私たちのために具体的なオブジェクトを作成することであるため、依存性の逆転（インジェクションではない）の原則に違反していません。

または、ファクトリが作成することを意図しているクラスを、ファクトリが作成することを意図しているクラスに渡しますか？もしそうなら、それは最初に工場を建設するという点を打ち負かすのではないでしょうか？インジェクターが基本的に工場のすべての仕事をしているので。

あなたが正しいです！

ファクトリパターンは作成パターンです。インスタンスを作成します。

依存関係注入パターンは、疎結合と依存関係の逆転（制御の逆転）に関するものです。これらのパターンは、別のインスタンスがその仕事を行う必要があるインスタンスを注入します。

それらはさまざまな問題に対処し、組み合わせて使用​​できます。例（多分それほど素晴らしいものではないかもしれませんが、うまくいくと思います）：

class Player {
    string name;
}

interface PlayerFactory {
    Person create();
}

class RealPlayerFactory : PlayerFactory {
    return GetPlayerFromDatabase();
}

class RandomPlayerFactory : PlayerFactory {
    Person result = new Person();
    result.name = GenerateRandomName();
    return result;
}

class Team {
    Team(PlayerFactory playerFactory) {
        for (int i=0; i < 11; ++i) {
            AddPlayer( playerFactory.create() );
        }
    }
}

依存性注入パターンを使用して、疎結合を導入します。

オブジェクトの作成を委任する必要がある場合は、ファクトリパターンを使用します。

6
Pellared

依存性注入を頻繁に使用する場合、コードを、機能と関数を保持するクラス/オブジェクトを含む部分と、前者の作成が行われ、依存関係が解決されるコードに分割します。後者は、

  • dIコンテナ
  • ファクトリークラス

したがって、DIはファクトリーの使用に反しません。実際、DIコンテナーなしでDIを実行すると、通常、多くのファクトリーが必要になります。

詳細については、こちら ブログ投稿 を参照してください。

8
Doc Brown