依赖注入vs工厂模式

引用的大多数使用依赖注入的例子，我们也可以使用工厂模式来解决。看起来当涉及到使用/设计时，依赖注入和工厂之间的区别是模糊或稀薄的。

曾经有人告诉我，你如何使用它才会有所不同!

我曾经使用StructureMap一个DI容器来解决一个问题，后来我重新设计了它来使用一个简单的工厂，并删除了对StructureMap的引用。

谁能告诉我它们之间的区别在哪里使用什么，这里的最佳实践是什么?

当前回答

我认为它们是正交的，可以一起使用。让我给你看一个我最近在工作中遇到的例子:

我们使用Java中的Spring框架进行DI。一个单例类(Parent)必须实例化另一个类(Child)的新对象，这些对象有复杂的协作者:

@Component
class Parent {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
    }

    void method(int p) {
        Child c = new Child(dep1, dep2, ..., depN, p);
        // ...
    }
}

在这个例子中，Parent必须接收DepX实例，并将它们传递给Child构造函数。问题在于:

Parent对Child的了解比它应该了解的要多母公司的合作者太多了向Child添加依赖项需要更改Parent

这时我意识到工厂非常适合这里:

它隐藏了Child类的所有真实参数，就像Parent所看到的那样它封装了创建子节点的知识，这些知识可以集中在DI配置中。

这是简化的Parent类和ChildFactory类:

@Component
class Parent {
    // ...
    @Autowired
    Parent(ChildFactory childFactory) {
        this.childFactory = childFactory;
    }

    void method(int p) {
        Child c = childFactory.newChild(p);
        // ...
    }
}

@Component
class ChildFactory {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
        // ...
        this.depN = depN;
    }

    Child newChild(int p) {
        return new Child(dep1, dep2, ..., depN, p);
    }
}

2018-04-16 20:47:19

其他回答

依赖注入的一个缺点是它不能用逻辑初始化对象。例如，当我需要创建一个随机名称和年龄的字符时，DI不是工厂模式的选择。使用工厂，我们可以很容易地从对象创建中封装随机算法，它支持一种称为“封装变化”的设计模式。

2012-05-01 09:24:19

当使用工厂时，您的代码实际上仍然负责创建对象。通过DI，你可以将职责外包给另一个类或框架，这与你的代码是分开的。

2009-02-17 17:14:02

理论

这里有两点需要考虑:

谁创建对象:

[Factory]:你必须写如何创建对象。您有独立的Factory类，其中包含创建逻辑。 [依赖注入]:在实际情况下，这是由外部框架完成的(例如在Java中是spring/ejb/guice)。注入“神奇地”发生，无需显式地创建新对象。

它管理的对象类型:

[Factory]:通常负责有状态对象的创建 [依赖注入]:更可能创建无状态对象