6.6 概括

  当你了解一些基本原则时，DI并不特别困难，但随着你的学习，你肯定会遇到一些问题，这些问题可能会让你困惑一阵子。本章试图解决人们遇到的一些最常见的问题。
  与DI相关的最通用和最有用的设计模式之一是抽象工厂。 我们可以用它来转换原始的运行时值，如用户输入的字符串或数字，使之成为复杂的抽象实例。我们还可以将抽象工厂与IDisposable接口结合起来使用，以模拟短暂的依赖，如与外部资源的连接。

提示：用抽象工厂将运行时值转化为依赖。
提示： 模仿与抽象工厂的联系，创造一次性的依赖。

  有时出现的一个问题是依赖循环。这往往是因为API的要求太高而发生的。越是围绕查询范式设计的API，就越有可能出现循环。我们可以通过遵守好莱坞原则（告诉，不要问）来避免循环。具有无效签名的方法可以被重新设计为事件，这通常可以用来打破循环。如果重新设计是不可能的，我们可以通过将单一的构造器注入改为属性注入来打破一个循环。然而，这不应该随便做，因为它改变了消费者的语义。

提示： 用属性注入法打破循环

  构造器注入应该是你首选的DI模式；另外一个好处是，每次你违反单一责任原则时，它都会变得非常明显。当一个单一的类有太多的依赖时，这就是一个信号，我们应该以某种方式重新设计它。也许我们可以把它分成几个小的类，但有时我们需要把所有的功能保持在一个单一的类中。

提示： 通过重构到Facade服务来解决构造器过度注入问题。

  在这些情况下，我们可以通过在消费者和原始依赖之间插入一层Facade服务来提高抽象级别。执行这样的重构通常会产生积极的副作用，即这些Facade服务中的一些变成了以前未被发现的隐式域概念。把隐含的概念拉出来并使其显性化是对域模型的一种改进。
  当我们进行这些细枝末节的重构时，我们决不能忽视大局。 自动测试或工具可以帮助我们监测代码库的某些部分是否重新出现紧耦合现象。
  如果我们写了大量的单元测试（特别是如果我们使用测试驱动开发），紧耦合将很快表现为复杂和脆弱的测试代码。或者是不可能对应用程序的大块内容进行单元测试。

提示： 编写自动化测试以执行松耦合

  如果我们不写单元测试，紧耦合可能会被忽视，但我们可能会经历许多它的症状：随着代码库的发展，它变得越来越难以维护。 我们最初设想的漂亮干净的设计会慢慢侵蚀成意大利面条代码。增加一个新的功能需要我们在许多看似不相关的地方触碰代码库。
  这一章描述了DI中经常遇到的问题的解决方案。它与前面两章一起，构成了一个模式、反模式和重构的目录。这个目录构成了本书的第二部分。在第三部分，我们将转向DI的三个维度：对象构成、生命周期管理和交互。