我应该选择依赖注入还是工厂模式

Question

我正在研究依赖注入。我发现：引用依赖注入的大多数示例，我们也可以使用工厂模式来解决。

能否请您比较一下DI和Factory模式之间的强项/弱点？我应该总是选择依赖注入而不是工厂模式吗？还是取决于指定的项目？

我怎么知道什么是最好的解决方案？最佳做法是什么？

Answer 1

让我们看看它们之间的区别。

使用DI，可以在外部创建对象并“注入”对象，以供客户端对象使用。 注入通常通过构造函数完成。

但是，在复杂的情况下，通常会注入一个DI容器来创建依赖项对象，包括所有子依赖项。因此，它看起来像是“抽象工厂”！

对于Abstract Factory，将注入具体Factory类的实例，并且依赖关系对象将由客户端对象实例化。

因此，当您考虑这两种情况下，DI和Abstract Factory几乎相同时，工厂对象将传递给客户端以使其能够创建其依赖项。

仅在简单情况下，相关对象是在外部创建的，并传递给客户端对象。这就是“策略模式”的工作原理。

由于DI容器现在如此流行，并且在框架中得到了如此广泛的使用，所以它们已经有效地取代了Abstract Factory，至少作为一种经常被提及的模式。 DI容器比抽象工厂所设想的要复杂得多（我相信）。

所以没有最佳实践！

Answer 2

@pcperth：来自Xamarin大学，他们提到两者都有优点和缺点：

此外，我认为使用DI首先创建类，并且我们的程序在运行时将其保留，然后浪费内存（以防我们需要优化内存）。

这是我的看法，但是实际上我不知道什么是更好的，或者在特定情况下应该使用。然后我需要在那里进行讨论。

加油！

Answer 3

我喜欢在接口上使用简单的依赖项注入。 只需将实现接口的对象传递给构造函数即可。

这还有一个额外的优势，您可以轻松模拟界面并在构建服务器/计算机上运行测试。由于Xamarin的部署会花费很长时间，因此请尝试使用单元测试进行尽可能多的操作。

Answer 4

您应该同时使用两者。

Factory旨在根据给定的参数找到接口的正确实现，并返回该接口的实例。解决类不能同时实例化自身和执行其他操作的问题的一种方法，因为它违反了SRP。

DI是通常通过将参数传递给实际类的构造函数来注入依赖项。之所以需要它，是因为高级代码不应该知道它使用的是低级代码的实现，只是该实现与某个接口相对应。否则我们将违反DIP。

因此工厂与DI非常兼容。实际上，DI容器只是一个自动化工厂，它从注释，配置文件等中提取信息，以便能够创建Applcation实例并注入其依赖项。当然，它的依赖项也具有依赖项，依此类推，因此，如果您手动编写它，将需要很长的代码，因此很有可能是上帝的对象。您可以通过定义工厂来解决此问题，这会缩短工厂的时间，但是人们更喜欢自动化。