4
엄격하게 분리 된 인터페이스가 필요한 모듈에서 작업하고 있습니다. 특히 루트 객체 (데이터 소스)를 인스턴스화 한 후에는 사용자가 인터페이스를 통해 객체 모델과 상호 작용하기로되어 있습니다. 나는이 팩토리를 호출하는 실제 팩토리 객체를 가지고 있는데,이 인터페이스를 구현하는 인스턴스를 제공하기 위해 공급자를 호출한다. 이를 위해, 나는 데이터 소스에 몇 가지 방법을 제공했습니다 : 나는 (단순화하기 위해 즉석에서 몇 가지 세부 사항을 수정 한좋은 팩토리 메소드 구현입니까?
public class MyDataSource
{
private Dictionary<Type, Type> providerInterfaceMapping = new Dictionary<Type, Type>()
{
{ typeof(IFooProvider), typeof(FooProvider) },
{ typeof(IBarProvider), typeof(BarProvider) },
// And so forth
};
public TProviderInterface GetProvider<TProviderInterface>()
{
try
{
Type impl = providerInterfaceMapping[typeof(TProviderInterface)];
var inst = Activator.CreateInstance(impl);
return (TProviderInterface)inst;
}
catch(KeyNotFoundException ex)
{
throw new NotSupportedException("The requested interface could not be provided.", ex);
}
}
}
를 예를 들어, 구현 인스턴스에 전달 된 매개 변수를 포함하지 않는이 코드 그것은 만들어졌습니다). 이것은 C#에서 팩토리 메소드를 구현하기위한 좋은 일반적인 접근 방법입니까?
첫 번째 요지를 잘 모르겠습니다. 클라이언트는 FooProvider에 액세스 할 수 없으며 IFooProvider에만 액세스 할 수 있습니다. FooProvider는 어셈블리 내부에 있습니다. 아니면 너의 의미를 놓치니? –
Re : 두 번째 요점은 매개 변수를 사용하는 구현을 실제로 지원합니다. 질문에서 언급했듯이 샘플을 단순화하기 위해 생략했습니다. 그것은 약간 어색하지만 공급자는 모두 데이터 소스를 유일한 매개 변수로 사용하여 필요한 모든 것을 얻을 것으로 기대됩니다. 이를 통해 .ctor parm을 통해 제공 될 수있는 FakeDataSource를 만들 수 있으므로 공급자 구현은 유닛 테스트 중에 가짜에 의존 할 수 있습니다. 가짜 데이터 소스는 가짜 공급자 만 제공합니다. –
잘못된 가정을하면 유감스럽게 생각합니다. 즉, 내 비판의 일부가 귀하의 특정 상황에 적용되지 않는다는 것을 의미합니다. 그러나 나는 여전히 바퀴를 다시 만들 이유가 없다는 일반적인 조언을지지합니다. DI 컨테이너는 무료로이 작업을 수행 할 수 있습니다. –