如果使用模拟测试对象交互，则必须通过构造函数或特定方法传递协作者。在一个足够复杂的应用程序中，您将拥有许多彼此交互的小对象。如何在应用程序的最顶层管理整个对象图的构造？简而言之，您如何处理以下事项：
// arbitrarily complex
A a = new A(new B(new C(new D(new ...)), new E(new ...)), new F(new G(new ...)));
a.doSomething();
在这种情况下，似乎依赖注入容器是最佳解决方案。是否还有其他简化依赖关系管理的好策略？
答案 0 :(得分：2)
给出的例子只是穷人的DI 。只要你在应用程序的组合根（入口点）中将自己约束到composing the entire object graph，你就会做得很好。 （顺便说一下，我最近听到Dan North将此称为'new'是新的'new' - 暗指Java社区中的人们开始回归这种构建对象图的方式而不是使用容器）。
但是，只要您遵循Register Resolve Release模式，您也可以使用DI容器。特别是在基于请求的应用程序（Web应用程序和服务）中，管理生命周期对于穷人的DI来说可能很复杂，因此在这些类型的应用程序中，容器可能非常有用。
答案 1 :(得分：0)
据我所知，控制所有这些依赖项的唯一方法是创建一个可以传递的通用Context对象（但即使它有复杂性），或者使用IoC和构造函数注入。 / p>
特别是在您给出的示例中，CI是一个很好的解决方案，因为您可以通过配置容器来管理复杂性。
只是我的2美分......