依赖注入可以被认为是工厂方法模式的替代品吗？ [关闭]答案

【问题标题】：Can Dependency Injection be considered to be a replacement for factory method pattern? [closed]依赖注入可以被认为是工厂方法模式的替代品吗？ [关闭]
【发布时间】：2018-04-30 18:35:21
【问题描述】：

根据维基百科

在基于类的编程中，工厂方法模式是一种创建模式，它使用工厂方法来处理创建对象的问题，而不必指定将要创建的对象的确切类。

在依赖注入中（我有 spring 的经验，所以这可能是在那种情况下），我们为使用接口定义的每个类都有变量，并将具体实例化留给 DI 框架。

我是否遗漏了什么，或者这些可以互换使用？

【问题讨论】：

Spring中的应用上下文是一个bean工厂，所以我的回答是“是”。当您意识到 DI 需要一个 bean 工厂时，也许微妙之处就出现了，但还有更多（例如前和后 bean 处理器等）
@duffymo 是的 Spring 远不止于此，但我只是根据 IoC 和 DI 考虑它，而不是专门从框架的角度考虑它。
主要基于意见 - 许多好的问题会根据专家经验产生一定程度的意见，但这个问题的答案往往几乎完全基于意见，而不是事实、参考资料或特定专业知识。在尝试提出更多问题之前，请阅读What types of questions should I avoid asking?。
在构造函数是原始依赖注入并且也称为穷人依赖注入框架的上下文中考虑您的问题，还考虑到每个DI 框架具有 Providers 的概念，它们是 依赖项的工厂，您用于 Inject 用于后期绑定的依赖项，很明显它不是就像你说的那样清晰。
工厂方法模式是关于子类能够覆盖一些实例化对象的“创建”方法。依赖注入是关于通过“注入”（在最简单的情况下通过构造函数）替换属性的直接实例化。在我看来，这些想法完全不同。

标签： java design-patterns dependency-injection

【解决方案1】：

依赖注入可以被认为是工厂的替代品吗方法模式？

是的，但依赖注入甚至超越了。
因此，您应该将其视为设计方面的改进。

这两种方式提供了非常接近的设施是对的。
但还要注意，依赖注入原则与原始工厂模式有一些真正的不同：依赖倒置原则。
我非常喜欢好莱坞的比喻来说明：“不要打电话给我们，我们会打电话给你”。
这是必不可少的，因为它减轻了客户端类查找其依赖项：框架为您执行/（“调用”以收回隐喻）它。
因此，客户端不再与工厂结构（以及与之相关的样板代码）耦合，只需要定义它们的依赖关系，这些依赖关系就会被注入。

【讨论】：

依赖注入和工厂方法是不同的模式。它们可以一起使用。它们可以单独使用。一个不能替代另一个。 Erich Gamma 有 noted 在一本“重构的”设计模式书中，GoF 将添加依赖注入作为与 Factory 一起创建的模式。
@jaco0646 我没说这是相同的模式，它们不能一起使用。