Factoryパターンと組み合わせてDependency Injectionを使用する方法

任意のタイプのファイルの解析を担当するモジュールを検討してください。ここですでに説明したように、この問題に取り組むために戦略パターンを使用することを考えています。この質問に進む前に、リンクされた投稿を参照してください。

product.xmlファイルのコンテンツを必要とするクラスBを検討してください。このクラスは、XMLファイルを解析するために、Parserインターフェースの適切な具象実装者をインスタンス化する必要があります。適切な具象実装者のインスタンス化をファクトリに委任して、クラスBが「has-a」ファクトリになるようにすることができます。ただし、クラスBは、具体的な実装者をインスタンス化するためにファクトリに「依存」します。これは、クラスBのコンストラクターまたはセッターメソッドをFactoryに渡す必要があることを意味します。

したがって、ファイルを解析する必要があるファクトリとクラスBは、互いに密接に結合されます。私はこれまで説明してきたことについて完全に間違っている可能性があることを理解しています。私は、注入される依存関係がファクトリであるシナリオで依存関係の注入を使用できるかどうか、そしてこれを実装する正しい方法は何であるかを知りたいので、ユニットテストでファクトリをモックするなどの領域を活用できます。

これを行う正しい方法は、インターフェイスに依存し、そのインターフェイスの実装をクラスBに挿入することです。

インターフェースは、あなたが頼ることができる最も薄いものにすぎません-私はそれをほんの少しの煙をつかもうとすることに例えます。コードは何かに結合する必要があります。さもなければ何もしませんが、インターフェースへの結合はできる限り分離されていますが、インターフェースは必要な機能をすべて提供できます。

したがって、クラスBのコンストラクターが必要なクラスへのインターフェースを取得し、そのクラスをインターフェースの実装者としてファクトリに生成させます。ファクトリに依存せず、インターフェイスに依存し、ファクトリにそのファクトリの実装を提供します。

そのため、依存性注入を使用しますが、それは何の問題もありません。依存性注入（特に単純なコンストラクター注入）は、「通常の」方法で行う必要があります。アプリ内でmainできるだけ新しい（そしての最初の行に近い）新しいものを先送りし、ものを作成するために特別に設計されたクラスで新しい呼び出しを非表示にします。

結論：依存関係を注入することをためらわないでください。それは物事を行う通常の方法でなければなりません。

あなたの前提はここでは少し混乱していると思います、あなたはファクトリを注入することについて話しますが、ファクトリパターンは、DIフレームワークが普及していないときに依存性注入フレームワークが行うことのサブセットを行うことを目的とした創造的なパターンですそのため便利です。ただし、DIフレームワークがある場合、DIフレームワークはファクトリが満たすはずの目的を果たすことができるため、実際にはファクトリは必要ありません。

そうは言っても、依存関係の注入と、一般的な使用方法について少し説明しましょう。

依存性注入を行うにはさまざまな方法がありますが、最も一般的なのはコンストラクター注入、プロパティ注入、および直接DIContainerです。プロパティインジェクションはほとんどの場合間違ったアプローチであるため（時々正しいアプローチです）、コンストラクターインジェクションについてお話します。DIContainerアクセス​​は、他のアプローチのいずれかを絶対に行えない場合を除いて好ましくありません。

コンストラクターインジェクションは、依存関係のインターフェイスと、その依存関係の具体的な実装を知っているDIContainer（またはファクトリー）があり、そのインターフェイスに依存するオブジェクトが必要な場合は、構築時にファクトリーから実装を渡します。それ。

すなわち

IDbConnectionProvider connProvider = DIContainer.Get<IDbConnectionProvider>();
IUserRepository userRepo = new UserRepository(connProvider);
User currentUser = userRepo.GetCurrentUser();

多くのDIフレームワークは、DIContainerがUserRepositoryのコンストラクターで具体的な実装を知っているインターフェイスを検査し、それらを自動的に渡す場所まで、これを大幅に簡素化できます。この手法は頻繁にInversion of Controlと呼ばれますが、DIとIoCはどちらも頻繁に交換される用語であり、あいまいな（ある場合）違いがあります。

ここで、包括的なコードがDIContainerにアクセスする方法を知りたい場合は、アクセスするための静的クラスを使用するか、ほとんどのDIフレームワークでDIContainerを更新することができます。指定されたインターフェースに対して具体的であるとわかっている型の内部シングルトン辞書へのラッパー。

つまり、コード内の任意の場所でDIContainerを更新し、インターフェイスとコンクリートの関係を知るために既に設定したものと同じDIContainerを効果的に取得できます。DIContainerを直接操作してはならないコードの部分からDIContainerを隠す通常の方法は、必要なプロジェクトにのみDIフレームワークへの参照があるようにすることです。

他の何かを渡すのと同じように、依存性注入を介してファクトリーを渡すことができます。状況の再帰性が混乱を招かないようにしてください。私はそれを実装することについて他に何を言うべきかわかりません-あなたはすでに依存性注入を行う方法を知っています。

DIを使用して、工場にかなり定期的に注入します。

工場への注入に問題はありません。「親」オブジェクトのビルド中に必要な依存関係の種類を決定できない場合は、標準的な方法です。例がそれを最もよく説明すると思います。Javaがわからないので、c＃を使用します。

class Parent
{
    private IParserFactory parserFactory;
    public Parent(IParserFactory factory)
    {
        parserFactory = factory
    }

    public ParsedObject ParseFrom(string filename, FileType fileType)
    {
        var parser = parserFactory.CreateFor(fileType);
        return parser.Parse(filename);
    }
}