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

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

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

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

基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。

那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。

在过去的6个月里，我一直在广泛使用Guice (Java DI框架)。虽然总的来说我认为它很棒(特别是从测试的角度来看)，但也有一些缺点。最值得注意的是:

Code can become harder to understand. Dependency injection can be used in very... creative... ways. For example I just came across some code that used a custom annotation to inject a certain IOStreams (eg: @Server1Stream, @Server2Stream). While this does work, and I'll admit has a certain elegance, it makes understanding the Guice injections a prerequisite to understanding the code. Higher learning curve when learning project. This is related to point 1. In order to understand how a project that uses dependency injection works, you need to understand both the dependency injection pattern and the specific framework. When I started at my current job I spent quite a few confused hours groking what Guice was doing behind the scenes. Constructors become large. Although this can be largely resolved with a default constructor or a factory. Errors can be obfuscated. My most recent example of this was I had a collision on 2 flag names. Guice swallowed the error silently and one of my flags wasn't initialized. Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.

既然我已经抱怨过了。让我说，我将继续在我当前的项目中(很可能是在下一个项目中)使用Guice。依赖注入是一种非常强大的模式。但它肯定会让人困惑，无论你选择什么依赖注入框架，你几乎肯定会花一些时间咒骂。

另外，我同意其他发帖者的观点，依赖注入可能被过度使用。

有一件事让我对DI有点不安，那就是假设所有注入的对象都很容易实例化，而且不会产生副作用- or -依赖关系被频繁使用，以至于它超过了任何相关的实例化成本。

当依赖项在消费类中不经常使用时，这一点可能很重要;比如IExceptionLogHandlerService。显然，这样的服务很少在类中调用(希望:))——大概只在需要记录异常时调用;然而，规范的构造器-注入模式……

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

    ' ...
End Class

.．.要求提供该服务的“活动”实例，该死的成本/副作用。并不是说它可能会这样做，但是如果构建这个依赖实例涉及到服务/数据库命中，或配置文件查找，或在释放之前锁定资源，该怎么办呢?如果该服务是按需构建的、服务定位的或工厂生成的(它们都有各自的问题)，那么您将只在必要时才承担构建成本。

Now, it is a generally accepted software design principle that constructing an object is cheap and doesn't produce side-effects. And while that's a nice notion, it isn't always the case. Using typical constructor-injection however basically demands that this is the case. Meaning when you create an implementation of a dependency, you have to design it with DI in mind. Maybe you would have made object-construction more costly to obtain benefits elsewhere, but if this implementation is going to be injected, it will likely force you to reconsider that design.

顺便说一下，某些技术可以通过允许延迟加载注入的依赖项来缓解这个问题，例如，提供一个Lazy<IService>实例类作为依赖项。这将改变依赖对象的构造函数，并使其更加了解实现细节，例如对象构造开销，这也可以说是不可取的。

同样的基本问题，你经常遇到的面向对象编程，样式规则和其他一切。这是可能的——事实上是非常常见的——做太多的抽象，添加太多的间接，并且通常在错误的地方过度地应用好的技术。

您应用的每个模式或其他构造都会带来复杂性。抽象和间接分散了信息，有时会移除了无关的细节，但有时也会让人更难理解到底发生了什么。你应用的每一条规则都会带来不灵活性，排除了可能是最佳方法的选择。

重点是编写能够完成这项工作的代码，并且是健壮的、可读的和可维护的。你是软件开发人员，而不是象牙塔建造者。

相关的链接

平台内效应

不要让建筑宇航员吓到你

可能依赖注入最简单的形式(别笑)是一个参数。依赖代码依赖于数据，而数据是通过传递参数的方式注入的。

是的，这很愚蠢，而且它没有解决依赖注入的面向对象问题，但是函数式程序员会告诉你(如果你有第一类函数)这是你唯一需要的依赖注入。这里的重点是举一个简单的例子，并展示潜在的问题。

以这个简单的传统函数为例。c++语法在这里并不重要，但我必须以某种方式拼写它……

void Say_Hello_World ()
{
  std::cout << "Hello World" << std::endl;
}

我有一个依赖，我想提取出来并注入-文本“Hello World”。很容易…

void Say_Something (const char *p_text)
{
  std::cout << p_text << std::endl;
}

为什么它比原来的更不灵活呢?如果我决定输出应该是Unicode。我可能想从std::cout切换到std::wcout。但这意味着我的字符串必须是*wchar_*t，而不是char类型的。要么必须更改每个调用方，要么(更合理地)将旧的实现替换为转换字符串并调用新实现的适配器。

这是维修工作如果我们保留原来的就不需要了。

如果它看起来微不足道，那么看看这个来自Win32 API的真实函数……

函数(winuser.h)

这有12个“依赖项”需要处理。例如，如果屏幕分辨率变得非常大，也许我们将需要64位的坐标值-和另一个版本的CreateWindowEx。是的，已经有一个旧版本仍然存在，它可能会在幕后映射到新版本……

创造温杜瓦宏(winuser宏)

这些“依赖关系”不仅仅是原始开发人员的问题——每个使用该接口的人都必须查找依赖关系是什么，它们是如何指定的，以及它们的含义，并确定为他们的应用程序做什么。这就是“明智的默认”可以让生活简单得多的地方。

面向对象的依赖注入在原理上没有什么不同。无论是在源代码文本中还是在开发人员时间中，编写类都是一种开销，如果编写该类是为了根据某些依赖对象规范提供依赖项，那么依赖对象将被锁定为支持该接口，即使需要替换该对象的实现。

这些都不应该被解读为依赖注入是不好的——远非如此。但是任何好的技术都可能被过度地应用在错误的地方。就像不是每个字符串都需要提取出来并转化为参数一样，也不是每个低级行为都需要从高级对象中提取出来并转化为可注入的依赖项。

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