问这是一个好的工厂方法实现吗？
EN

Stack Overflow用户

提问于 2009-10-26 15:06:29

回答 5查看 702关注 0票数 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#中实现工厂方法，这是一个好的通用方法吗？

factory-method

腾讯云OCR文字识别特惠

文字识别限时抢购，热门产品低至14.9元

回答 5

Stack Overflow用户

回答已采纳

发布于 2009-10-26 15:19:05

你应该退后一步，问问使用工厂方法是不是一个好主意？在我看来，它不是。

工厂方法存在多个问题，您的示例说明了几个问题：

您需要对实现(除了IFooProvider之外的FooProvider)有一个硬引用，这正是您首先要避免的情况。即使您的其余代码只使用IFooProvider，您的库仍然与FooProvider紧密耦合。如果其他开发人员不知道您的工厂方法，他们可能会过来直接开始使用FooProvider。
您只支持具有默认构造函数的实现，因为您使用的是Activator.CreateInstance。这会阻止您使用嵌套依赖项。

我建议您考虑一下依赖注入(DI)，而不是尝试手动控制依赖项。每当您的代码需要一个IFooProvider时，就用构造函数注入来提供它。

票数 4

Stack Overflow用户

发布于 2009-10-26 15:41:55

不要重新发明您自己的 实现，而要使用现有的库，如Spring.NET或Microsoft Unity应用程序块。

注入依赖关系是一个常见的编程问题，你不应该自己去解决。有一些很好的轻量级库(我在上面提到过几个)可以很好地完成这项工作。它们同时支持定义依赖关系的声明式和命令式模型，并且非常擅长它们所做的事情。

票数 3

Stack Overflow用户

发布于 2009-10-26 15:19:59

从技术上讲这很好，但是大多数时候当我看到一个工厂时，它通常返回相同类型的接口，例如像IProvider而不是IFooProvider或IBarProvider，这对我来说是没有意义的。如果你打算使用FooProvider和BarProvider，为什么要为它们提供不同的接口呢？我会使用一个接口IProvider，并让FooProvider和BarProvider实现它。