我试图在工作中引入依赖注入(DI)模式，我们的一位主要开发人员想知道:如果有的话，使用依赖注入模式的缺点是什么?
注意，如果可能的话，我在这里寻找一个详尽的列表，而不是关于这个主题的主观讨论。
澄清:我谈论的是依赖注入模式(参见Martin Fowler的这篇文章)，而不是特定的框架，无论是基于xml的(如Spring)还是基于代码的(如Guice)，还是“自滚动”的框架。
Reddit的subreddit /r/programming上正在进行一些深入的讨论/咆哮/辩论。
当前回答
当您不断地使用技术来处理静态类型时，静态类型语言的假定好处似乎大大减少了。我刚刚采访的一家大型Java商店正在用静态代码分析绘制他们的构建依赖关系……它必须解析所有的Spring文件才能有效。
其他回答
两件事:
它们需要额外的工具支持来检查配置是否有效。
例如，IntelliJ(商业版)支持检查Spring配置的有效性，并将标记出配置中的类型违反等错误。如果没有这种工具支持，就无法在运行测试之前检查配置是否有效。
这就是为什么“蛋糕”模式(Scala社区所熟知)是一个好主意的原因之一:组件之间的连接可以由类型检查器检查。而注释或XML则没有这种好处。
这使得程序的全局静态分析非常困难。
像Spring或Guice这样的框架很难静态地确定容器创建的对象图将是什么样子。尽管它们在容器启动时创建了一个对象图，但它们没有提供有用的api来描述将要创建的对象图。
依赖注入是一种技术或模式，与任何框架无关。您可以手动连接依赖项。DI帮助您实现SR(单一职责)和SoC(关注点分离)。DI会带来更好的设计。从我的观点和经验来看，没有坏处。就像任何其他模式一样，你可能会弄错或误用它(但在DI的情况下很难)。
如果您使用框架将DI作为原则引入到遗留应用程序中，那么您可能犯的最大错误就是将其误用为服务定位器。DI+框架本身是伟大的，只是让事情变得更好，我看到它!从组织的角度来看，每一个新的过程、技术、模式……都有共同的问题:
你必须训练你的团队 您必须更改您的应用程序(这包括风险)
一般来说，你必须投入时间和金钱，除此之外，没有任何负面影响，真的!
代码可读性。由于依赖关系隐藏在XML文件中，因此您无法轻松地找出代码流。
仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。
这更像是吹毛求疵。但是依赖注入的一个缺点是，它使开发工具更难推理和导航代码。
具体来说，如果你在代码中控制-单击/命令-单击方法调用，它将带你到接口上的方法声明，而不是具体的实现。
这实际上是松散耦合代码(由接口设计的代码)的缺点，即使不使用依赖注入(即，即使只是使用工厂)也适用。但是依赖注入的出现真正鼓励了松耦合代码的普及，所以我想我应该提到它。
而且，松散耦合代码的好处远远超过这一点，因此我称之为吹毛求疵。尽管我工作了很长时间，知道如果您试图引入依赖注入，可能会遇到这种情况。
事实上，我敢大胆地猜测，对于依赖注入的每一个“缺点”，您都会发现许多优点远远超过它。
