design-patterns - 使用依赖注入(inject)有哪些缺点？

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center 寻求指导。

已关闭 11 年前。

我正在尝试将依赖注入(inject) (DI) 作为一种工作模式引入，我们的一位首席开发人员想知道:使用 dependency injection 的缺点是什么(如果有的话)模式？

请注意，如果可能的话，我在这里寻找详尽的列表，而不是对该主题的主观讨论。

<小时/>

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

<小时/>

一些精彩的进一步讨论/咆哮/辩论正在 Reddit's subreddit /r/programming 上进行。

Answer 1

几点:

• DI 会增加复杂性，通常是通过增加类的数量来实现，因为职责更加分散，但这并不总是有益的
• 您的代码将(在某种程度上)与您使用的依赖项注入(inject)框架(或者更一般地说，您决定如何实现 DI 模式)耦合
• 执行类型解析的 DI 容器或方法通常会产生轻微的运行时损失(非常微不足道，但确实存在)

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