什么时候使用工厂设计模式而不是依赖注入？

Question

我对设计模式缺乏经验，当我研究它们时，我对工厂模式的应用感到困惑。DI对类的解耦不会比工厂做的更多吗？或者在某些情况下使用DI会过分吗？我将DI理解为在通过实现IoC实现解耦方面超越工厂的一步。

Answer 1

什么时候使用工厂设计模式而不是依赖注入？

(强调我的)。

永远不要，因为它们不是相互排斥的。工厂根据一组规则提供对象的实例。依赖注入告诉代码单元它的依赖项是什么，而不是询问那些依赖项。它们既提供了脱钩机制，又相互补充。

关键是不要使用静态工厂。相反，将工厂实现与其契约(例如通过接口)分离，并将工厂注入使用它的代码单元中。

所以不要有办法，如

void Foo()
{
    var someObject = Factory.Create(someConditions);
}

相反，请做：

void Foo(IFactory factory)
{
    var someObject = factory.Create(someConditions);
}

Answer 2

David Arno的回答是将您从静态工厂升级到抽象工厂。我不会反对给你额外的多态力量。但我不得不指出，Foo仍然知道如何获得someObject。知道会阻碍你。

将此与纯依赖注入解决方案进行对比：

class Foo {
    public Foo(SomeObject someObject) {
        this.someObject = someObject;
    }
    private SomeObject someObject; 
}


static void Main()  
{  
    // All construction code for long lived objects goes here
    SomeConditions someConditions = ...;
    Foo foo = new Foo(
        new Factory().Create(someConditions)
    );    

    // Now start the whole thing ticking 
    foo.start();

    //Since main is only called once everything built above only exists once.
}  

这样做，Foo不知道在哪里可以找到someObject。因为它不知道它不在乎。从一家工厂，一个新的，或者一个测试那里得到它，这也同样令人高兴。最终可能会变得很重要。

如果您采取相反的方式，让Foo知道工厂的存在，那么如果让工厂提供许多依赖项，您应该小心这会如何导致服务定位器模式。我不会告诉您永远不要使用它，但是要注意它是如何批评的，因为它传播了周围对定位器的感知。