我已经阅读了很多关于 IoC 和 DI 的文章，但我不太相信在大多数情况下使用它们会收获很多。
如果您正在编写需要可插拔组件的代码，那么是的，我看到了它的价值。但如果你不是，那么我质疑将依赖项从类更改为接口是否真的能让你获得任何好处，除了更多的打字。
在某些情况下，我可以看到 IoC 和 DI 在哪些方面有助于模拟，但如果您不使用模拟或 TDD，那么它的价值是什么？这是 YAGNI 的案例吗？
【问题讨论】：
标签： dependency-injection inversion-of-control yagni
我怀疑你会有任何关于它的硬数据，所以我会添加一些想法。
首先，您不使用 DI（或其他 SOLID 原则），因为它可以帮助您进行 TDD。反过来说，您执行 TDD 是因为它可以帮助您进行设计 - 这通常意味着您获得的代码遵循这些原则。
讨论为什么要使用接口是另一回事，请参阅：https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces。
我假设你同意让你的类做许多不同的事情会导致代码混乱。因此，我假设您已经开始使用 SRP。
因为您有不同的类来做特定的事情，所以您需要一种方法来关联它们。如果您将它们与类（即构造函数）相关联，您将获得大量使用特定版本的类的代码。这意味着对系统进行更改将很困难。
您将需要更改系统，这是软件开发的一个事实。你可以打电话给 YAGNI 关于不添加特定的额外功能，但不是说你不需要更改系统。就我而言，这是非常重要的，因为我每周都会进行冲刺。
我使用通过代码完成配置的 DI 框架。通过非常小的代码配置，您可以连接许多不同的关系。因此，当您取消关于接口与具体类的讨论时，您实际上是在节省打字而不是相反。同样对于具体类在构造函数上的情况，它会自动将其连接起来（我不必配置）构建其余的关系。它还允许我控制一些对象的生命周期，特别是我可以将一个对象配置为一个 Singleton 并且它始终处理一个实例。
另请注意，仅使用这些做法并不会增加开销。第一次使用它们是导致开销的原因（因为学习过程 + 在某些情况下思维方式改变）。
底线：您不需要将所有这些构造函数调用放在各处以加快速度。
【讨论】：
DI 最显着的收益不一定是由于使用了接口。您实际上不需要使用接口来获得依赖注入的有益效果。如果只有一个实现，您可能可以直接注入它，并且可以混合使用类和接口。
您仍然处于松散耦合状态，如果需要，您可以通过几个按键来在很多开发环境中引入该接口。
我无法给出关于松散耦合价值的硬数据，但只要我记得，它就一直是教科书中的一个愿景。现在是真的了。
当涉及到大型结构的层次结构时，DI 框架还为您提供了一些非常惊人的功能。我建议您寻找一个功能齐全的框架，而不是寻找最精简的 DI 框架。少并不总是多，至少在学习新的编程方式时是如此。 那么你可以少花钱。
【讨论】：
除了测试之外，松耦合也是值得的。
我从事嵌入式 Java 系统的组件工作，该系统在启动后具有固定的对象配置（大约 50 个不同的对象）。
第一个组件是没有依赖注入的遗留代码，以及到处创建的子对象。现在发生了好几次，对于一些修改，一些代码需要与一个只有三个构造函数可用的对象对话。那么除了向构造函数添加另一个参数并传递它之外，您还能做什么，或者甚至将其存储在一个字段中以便稍后传递。从长远来看，事情变得比现在更加纠结。
我从头开发的第二个组件，使用了依赖注入（当时不知道）。也就是说，我有一个工厂，它构建了所有对象并在需要知道的基础上注入。添加另一个依赖项很容易，只需将其添加到工厂和对象构造函数（或添加一个 setter 以避免循环）。无需触及无关代码。
【讨论】：