oop – 为什么依赖注入比使用工厂更好?

我一直在阅读依赖注入,我理解在 XML中指定依赖关系的吸引力,就像许多框架中所做的那样.我在一个大型系统上工作,我们通常会调用工厂来获取具体对象,并且我很难理解为什么手动注入依赖关系,如 in this Wikipedia article所示,据说更好.

在我看来,调用工厂更好,因为:

>调用代码不需要知道或关心特定的依赖关系存在.
>如果向被调用添加新依赖项,则无需更改调用代码.
>调用代码不需要任何专用于选择要注入的具体实例的逻辑.

在我看来,当调用代码必须决定依赖的具体类时,依赖注入只能提供好处.几乎像“这是我的数据,现在处理它.”

我错过了什么吗?

更新:
为了澄清,我们现有的代码主要是直接调用工厂.因此,要获得一个新的Ball对象,您会看到如下代码

Ball myBall = BallFactory.getobject();

实现了许多这些工厂以允许运行时注册新的具体对象类型 – 插件框架.

因此,在查看一些初始注释之后,看起来像DI我的调用代码通常不会传递给Ball对象,而是BallFactory.我想这样做的好处是该类可能更通用,因为它甚至没有耦合到它使用的工厂.

解决方法

两者都不比另一个“更好”;您可以单独使用依赖注入,单独使用工厂,或者使用这些依赖注入.

此外,您提到的有关工厂的所有3点对于依赖注入同样有效.请记住,依赖关系可以在任何时间点注入,而不一定是直接的“调用代码”.事实上,这就是DI框架为您所做的事情 – 它基本上是一个巨大的工厂,它创建您的主应用程序对象并为您注入所有依赖项.

只有当您的代码需要能够在运行时创建依赖关系的新实例时,显式使用工厂才有用.否则,在应用程序启动期间简单地使用DI框架注入所有静态依赖项会简单得多.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...