我试图在工作中引入依赖注入(DI)模式，我们的一位主要开发人员想知道:如果有的话，使用依赖注入模式的缺点是什么?
注意，如果可能的话，我在这里寻找一个详尽的列表，而不是关于这个主题的主观讨论。
澄清:我谈论的是依赖注入模式(参见Martin Fowler的这篇文章)，而不是特定的框架，无论是基于xml的(如Spring)还是基于代码的(如Guice)，还是“自滚动”的框架。
Reddit的subreddit /r/programming上正在进行一些深入的讨论/咆哮/辩论。
当前回答
基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。
那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。
其他回答
基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。
那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。
两件事:
它们需要额外的工具支持来检查配置是否有效。
例如，IntelliJ(商业版)支持检查Spring配置的有效性，并将标记出配置中的类型违反等错误。如果没有这种工具支持，就无法在运行测试之前检查配置是否有效。
这就是为什么“蛋糕”模式(Scala社区所熟知)是一个好主意的原因之一:组件之间的连接可以由类型检查器检查。而注释或XML则没有这种好处。
这使得程序的全局静态分析非常困难。
像Spring或Guice这样的框架很难静态地确定容器创建的对象图将是什么样子。尽管它们在容器启动时创建了一个对象图，但它们没有提供有用的api来描述将要创建的对象图。
它可以增加应用启动时间，因为IoC容器应该以适当的方式解析依赖关系，有时需要进行多次迭代。
以下几点:
DI增加了复杂性，通常是通过增加类的数量，因为责任分离得更多，这并不总是有益的 您的代码将(在某种程度上)耦合到您使用的依赖注入框架(或者更一般地说，如何决定实现DI模式) 执行类型解析的DI容器或方法通常会导致轻微的运行时损失(非常可以忽略不计，但它确实存在)
通常，解耦的好处是使每个任务更易于阅读和理解，但增加了编排更复杂任务的复杂性。
仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。
