当您不断地使用技术来处理静态类型时，静态类型语言的假定好处似乎大大减少了。我刚刚采访的一家大型Java商店正在用静态代码分析绘制他们的构建依赖关系……它必须解析所有的Spring文件才能有效。

它可以增加应用启动时间，因为IoC容器应该以适当的方式解析依赖关系，有时需要进行多次迭代。

控制反转(不是完全依赖注入，但已经足够接近了)最大的“缺点”是，它倾向于去掉一个点来查看一个算法的概述。这基本上就是当你有解耦的代码时所发生的事情——在一个地方查看的能力是紧密耦合的产物。

我不认为存在这样的列表，但是试着阅读这些文章:

DI会模糊代码(如果你没有使用好的IDE) Bob叔叔认为，误用IoC会导致糟糕的代码。 需要注意过度设计和创造不必要的多功能性。

这是我自己的第一反应:基本上任何模式都有同样的缺点。

学习是需要时间的 如果误解了，就会弊大于利 如果走到极端，工作量可能会超过收益

没有任何DI的代码会面临众所周知的陷入意大利面条代码的风险——一些症状是类和方法太大，做太多，不容易更改、分解、重构或测试。

大量使用DI的代码可以是Ravioli代码，其中每个小类就像一个单独的Ravioli块——它只做一件小事，并且遵循单一责任原则，这是很好的。但是从类本身来看，很难看到系统作为一个整体在做什么，因为这取决于所有这些小部分是如何组合在一起的，这是很难看到的。它看起来就像一大堆小东西。

通过避免大型类中大量耦合代码的意大利面复杂性，您将面临另一种复杂性的风险，其中有许多简单的小类，它们之间的交互非常复杂。

我不认为这是一个致命的缺点- DI仍然是非常值得的。在某种程度上，小班级只做一件事的馄饨风格可能是好的。即使过度，我也不认为它像意大利面条代码那样糟糕。但是要避免它，第一步是要意识到它可能会走得太远。点击链接了解如何避免这种情况。