如何避免依赖注入构造函数的疯狂？

Question

我发现我的构造函数开始看起来像这样：

 public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

随着不断增加的参数列表。由于“容器”是我的依赖注入容器，为什么我不能这样做：

 public MyClass(Container con)

每节课？缺点是什么？如果我这样做，感觉就像我在使用美化的静电。请分享您对 IoC 和疯狂的依赖注入的看法。

原文由 JP Richardson 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

你是对的，如果你使用容器作为服务定位器，它或多或少是一个美化的静态工厂。出于多种原因， 我认为这是一种反模式（另请参阅我书中的 摘录）。

构造函数注入的一个美妙好处是它使违反 单一职责原则 的行为变得非常明显。

发生这种情况时，就该 重构为 Facade Services 了。简而言之，创建一个新的、更 粗粒度的 接口，隐藏您当前需要的部分或所有细粒度依赖项之间的交互。

原文由 Mark Seemann 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

我认为您的类构造函数不应该引用您的 IOC 容器周期。这表示您的类和容器之间存在不必要的依赖关系（IOC 试图避免的依赖类型！）。

原文由 derivation 发布，翻译遵循 CC BY-SA 2.5 许可协议