您可以在这个链接中查看两种(和其他)方法在实际示例中的比较。

基本上，当需求发生变化时，如果您使用工厂而不是DI，您最终会修改更多的代码。

这对于手动DI也是有效的(例如，当没有外部框架为你的对象提供依赖关系，但你在每个构造函数中传递它们时)。

理论

这里有两点需要考虑:

谁创建对象:

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

它管理的对象类型:

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

关于如何在一个项目中同时使用工厂注入和依赖注入的实例

我们想要建造什么

用于创建包含多个名为orderline的条目的订单的应用程序模块。

体系结构

让我们假设我们想要创建以下分层架构:

域对象可以是存储在数据库中的对象。 存储库(DAO)帮助从数据库检索对象。 服务为其他模块提供API。允许对订单模块进行操作。

域层和工厂的使用

数据库中的实体是Order和OrderLine。Order可以有多个orderline。

现在是重要的设计部分。这个模块之外的模块是否应该自己创建和管理orderline ?不。只有当订单与之关联时，订单行才应该存在。最好能将内部实现隐藏到外部类。

但是如何在不了解OrderLines的情况下创建Order呢?

工厂

想要创建新订单的人使用了OrderFactory(它将隐藏关于我们如何创建订单的细节)。

这就是它在IDE中的样子。域包外部的类将使用OrderFactory而不是Order内部的构造函数。

依赖注入 依赖注入更常用于无状态层，如存储库和服务。

OrderRepository和OrderService由依赖注入框架管理。 存储库负责管理数据库上的CRUD操作。Service注入存储库并使用它来保存/查找正确的域类。

注入框架是工厂模式的实现。

这完全取决于你的要求。如果您需要在应用程序中实现工厂模式，那么您的需求极有可能由众多注入框架实现中的一个来满足。

只有在任何第三方框架都不能满足您的需求时，您才应该推出自己的解决方案。编写的代码越多，需要维护的代码就越多。代码是一种负债而不是资产。

关于应该使用哪个实现的争论没有理解应用程序的体系结构需求那么重要。

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

我们使用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);
    }
}

我知道这个问题很老了，但我想补充一下我的观点，

我认为依赖注入(DI)在很多方面类似于可配置的工厂模式(FP)，从这个意义上说，你可以用DI做任何事情，你也可以用这样的工厂来做。

实际上，如果你使用spring为例，你可以选择自动装配资源(DI)或做这样的事情:

MyBean mb = ctx.getBean("myBean");

然后使用'mb'实例来做任何事情。这不是一个对工厂的调用，它将返回一个实例吗??

我注意到的大多数FP示例之间唯一真正的区别是，您可以在xml或其他类中配置“myBean”是什么，框架将作为工厂工作，但除此之外是一样的事情，您当然可以有一个工厂来读取配置文件或根据需要获得实现。

如果你问我的意见(我知道你没有)，我相信DI做了同样的事情，但只是增加了开发的复杂性，为什么?

嗯，首先，为了让您知道用于DI自动装配的任何bean的实现是什么，您必须进入配置本身。

但是…您不必知道正在使用的对象的实现，这种承诺又如何呢?啐!严重吗?当你使用这样的方法时……你不就是写实现的那个人吗??即使你没有，你不是几乎所有的时间都在看如何实现它应该做什么??

最后一点，不管DI框架向你承诺了多少，你将构建与它解耦的东西，不依赖于它们的类，如果你正在使用一个框架，你将围绕它构建一切，如果你不得不改变方法或框架，这将不是一个简单的任务……!…但是，由于您围绕特定的框架构建所有内容，而不是担心什么是最适合您的业务的解决方案，那么在这样做时，您将面临一个更大的问题。

事实上，我所能看到的FP或DI方法的唯一真正的业务应用是，如果你需要在运行时改变正在使用的实现，但至少我所知道的框架不允许你这样做，你必须在开发时让所有的配置都完美无缺，如果你需要使用另一种方法。

因此，如果我有一个类，它在同一个应用程序的两个作用域中执行不同的操作(比如说，同一个公司的两个控股公司)，我必须配置框架来创建两个不同的bean，并调整我的代码以使用每个bean。这是不是和我只是写这样的东西是一样的

MyBean mb = MyBeanForEntreprise1(); //In the classes of the first enterprise
MyBean mb = MyBeanForEntreprise2(); //In the classes of the second enterprise

和这个一样:

@Autowired MyBean mbForEnterprise1; //In the classes of the first enterprise
@Autowired MyBean mbForEnterprise2; //In the classes of the second enterprise

这:

MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise1"); //In the classes of the first enterprise
MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise2"); //In the classes of the second enterprise

在任何情况下，您都必须更改应用程序中的某些内容，无论是类还是配置文件，但您必须重新部署它。

这样做不是很好吗?

MyBean mb = (MyBean)MyFactory.get("mb"); 

通过这种方式，您可以设置工厂的代码以在运行时获得正确的实现，这取决于登录的用户企业??这很有帮助。您只需添加一个带有新类的新jar，并在运行时设置规则(或者如果您保留此选项，则添加一个新的配置文件)，无需更改现有类。这将是一个动态工厂!

这不是比为每个企业编写两个配置，甚至为每个企业编写两个不同的应用程序更有帮助吗?

You can tell me, I don't need to do the switch at runtime ever, so I configure the app, and if I inherit the class or use another implementation I just change the config and redeploy. Ok, that can also be done with a factory. And be honest, how many times do you do this? maybe only when you have an app that's going to be used somewhere else in your company, and you are going to pass the code to another team, and they will do things like this. But hey, that can also be done with the factory, and would be even better with a dynamic factory!!

不管怎样，评论区是开放的，你可以杀了我。

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