私はclass A{}class B:A{}class C:A{}とclass D{} DはBとCを使用する必要があるメソッドを使用するために必要なメソッドを持っています。シンプル工場とIOC
公共D(B b, C c)
またはべき：私はおそらくDは、コンストラクタなどがありましたらDが
を使用する必要がありますことをAから継承する複数のクラスを持つことになり、将来的に
A 正しいクラスを返す単純な工場(F)を取得します。その後、コンストラクタはpublic D(F f)
Fは、列挙型を取得し、正しい型を返しますCreateInstanceメソッドを持つことになります。
完全注入は、すべて組成ルートに保持されます。 単純なファクトリは、コンストラクタを単純化します。
あなたはここに留意する必要がある問題を経由して、不透明な依存関係を導入しています工場のアプローチ。
public D(B b, C c)
{
}
依存関係が透明になり：この時点で
は、Dは次のようにコンストラクタを使用してB と C.に依存します。私。このクラスが仕事をするために必要なことは明らかです。これらのことは直接提供することができます。さらに、他の偽物を提供する偽の工場を用意することなく、偽物を直接提供できるので、自動化されたテストは少し簡単です。工場この明快さは減少しますが、利便性を追加し、及びに渡さなければならない依存関係の数を減らすことによって、将来のプルーフの程度を使用して
。
個人的に、私はまで直接依存関係を提供するに固執うコンストラクタの署名が扱いにくかったり、工場のようにより高いレベルの抽象化が明らかに必要でした。クラスがに依存していることは、Bと のように、ファクトリのような抽象化がわかりにくい可能性があるという明確な設計メッセージを出します。
私の意見では、BとCが同じインターフェイスを実装している場合、これを行う正しい方法はfactoryを渡すことです。また、具体的なタイプに依存するのを避ける代わりに、インターフェースに依存しています。これらの2つを具体的に取得しなければならない場合は、それぞれのインターフェースを追加し、そのインターフェースに依存するか、工場に行く必要があります。
（より完全な例ためthis questionを参照してください）
public enum XTypes
{
A,B,C...
}
public interface IXFactory
{
IX GetX(XTypes xType);
}
public interface IX
{
void SomeMethod()
}
//And I'd do A as an abstract class and rename to XBase
public class A : IX
{
public void SomeMethod() {}
}
public class D
{
public D(IXFactory xFactory)
{
XFactory = xFactory;
}
public void SomeMethod()
{
var x1 = XFactory.GetX(XTypes.A);
var x2 = XFactory.GetX(XTypes.C);
}
public IXFactory XFactory { get; set; }
}
私は個人的には、以下の場合に工場を置いていないでしょう。
IEnumerable<IDependency>IX自身が彼のキーが何であるかを宣言する（この場合はenum）、その後、工場の実装は本当にきれいですがあると便利です）、私は追加しますが必要になる場合があります。
- Castle Windosr（他のIOCコンテナでもそうです）TypedFactoryFacilityがあります。これはITypedFactoryComponentSelectorを実装して操作することができます。その後、自分でも実装する必要はありません。
*代わりにenumのあなたがIX<XRequestBase>にIXを変更することができ、その後TypedFactoryFacilityがマップされると、自動的に動作するオブジェクトを持つことになります場合は:)
クラスAは、抽象クラスまたはインタフェースですか？ –
その抽象クラスはnyのケースですが、もしdiffres idがどちらの場合でも答えが大好きならば。 – Nahum
これはインターフェイスとして実装されていますので、多くの 'types 'があります – Sherlock