设计模式 – 使用依赖注入的缺点是什么?

前端之家收集整理的这篇文章主要介绍了设计模式 – 使用依赖注入的缺点是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我试图在工作中引入DI作为模式,我们的主要开发人员想知道:使用依赖注入模式的缺点是什么?

注意我在这里寻找一个 – 如果可能的 – 详尽的列表,而不是主题主题讨论。

澄清:我在谈论依赖注入模式(参见Martin Fowler的this article),而不是一个特定的框架,无论是基于XML(如Spring)还是基于代码(如Guice)或“自我滚动”。

编辑:/r/programming这里有一些伟大的进一步讨论/咆哮/辩论。

几点:

> DI增加了复杂性,通常通过增加类的数量,因为责任分离得更多,这并不总是有益的
>你的代码将(有点)耦合到你使用的依赖注入框架(或更一般地你如何决定实现DI模式)
> DI容器或执行类型解析的方法通常会导致轻微的运行时惩罚(非常可忽略,但它在那里)

通常,解耦的好处使得每个任务更易于阅读和理解,但是增加了编排更复杂任务的复杂性。

猜你在找的设计模式相关文章