dependency-injection - 将 DI 容器注入（几乎）每个类是一种反模式吗？

Question

最近我发现自己不太关心定义类的依赖关系并将它们传递给构造函数，但我总是传递 DI 容器并将其保存在私有属性中。这样我的类就不会有非常明确的依赖关系，当我需要它时，我会从容器中获取所有东西。

虽然不知何故我对这个解决方案有不好的感觉（除了访问容器造成的开销），但我真的想不出太多的缺点。也许对依赖项的定义松散会降低类的可移植性，或者在重构时我会感到惊讶......？

你怎么看待这件事？

score 11 · Accepted Answer

绝对错误。不要将 DI 容器放入对象中；他们不需要知道或关心他们正在被注射。这不符合“不要给我们打电话；我们会打电话给你”。

反过来说：整个应用程序都知道 DI 引擎，但随后它会从中获取所需的 bean。

我想您可能会争辩说，注释会改变一些关系，因为现在 bean确实知道它们连接在一起的事实。但是当配置被外部化为 XML 时，bean 确实不知道 DI。

score 3 · Accepted Answer

这是一种反模式，我敢打赌你还没有为你的代码编写测试，这真的很糟糕。

当您开始编写测试时，您会发现您正在编写不可测试的代码，并且您是：

在您想为组件编写单元测试的那一天，您会后悔这个决定，您将要么重构代码，要么编写集成测试，而不是简单的单元测试（创建一个测试容器并将模拟注入这个容器）。

我的建议是阅读本指南以编写可测试的代码：（这是在谷歌努力工作的人使用的指南）

如果您愿意，可以从 Misko Hevery 的这些关于测试心理学和干净代码谈话的视频开始：

2 回答 2