当使用工厂进行依赖注入时，如何处理在对象实例化时我们不知道依赖类型的情况？答案

【问题标题】：When Dependency Injection using Factories how to Handle cases where we don't know the type of the dependency at Object Instantiation time?当使用工厂进行依赖注入时，如何处理在对象实例化时我们不知道依赖类型的情况？
【发布时间】：2012-05-08 15:58:03
【问题描述】：

我发现使用 new 关键字会导致难以测试代码。对此的解决方案似乎是在构造函数中传递依赖项并仅在工厂中实例化对象。但是，如果我们在对象实例化时不知道所有依赖项（或依赖项的类型）怎么办？这种情况如何处理？

例如，假设我们有一棵树，它可以有不同类型的节点。创建节点后，我们不知道其子节点的类型。

【问题讨论】：

你能提供一个具体的例子吗？我很难看出这是怎么回事......在你的树示例中，你只需将树的根作为单个依赖项传递。

标签： dependency-injection

【解决方案1】：

如果在创建时无法确定传入的内容，则需要某种形式的Abstract Factory，尽管在服务和不应反向引用服务的值类型之间划清界限通常很有用.

我为什么要笼统地回答？因为你问的是笼统的 - 如果你真的想得到一个有用的答案，请举一个更具体和上下文的例子，你正在寻找一个好的方法。

您尚未指定您是在查看依赖倒置原则还是 DI 框架或 Dependency management in libraries，它们有很多共同点，也有很多不同之处。

我怀疑（即使您似乎没有接触过 .NET 标签），正如@TrueWill 所推荐的那样，出色的Dependency Injection in .NET 书将帮助您理解所涉及的细微之处（无论您使用哪种语言或平台）重新使用——本书的前面只是相当独立于技术的模式——考虑到优秀的例子具有现实的复杂程度意味着这是可能的）。

【讨论】：

那么我们是不是通过依赖于工厂创建的对象的类的构造函数来注入Factory呢？
是的，这是有道理的。您真的应该花时间扩展您的问题，以便获得更深入的建议 - 通过编辑示例或在您对问题的理解发生变化时提出新问题。

【解决方案2】：

构造函数注入只是各种可能性中的一种。

您可以在 IoC（控制反转）容器中注册您的类型，并在需要时解析它们。

带有来自 Microsoft 的 Unity 应用程序块的 .Net 示例：

// When starting your application, you register your types:

var myContainer = new UnityContainer();
var logger = new Logger();
myContainer.RegisterInstance<ILogger>(logger);

// Later, when you need them, you can resolve them in your code:

var logger = myContainer.Resolve<ILogger>();

【讨论】：

这个例子可能会导致 OP 绕过 IoC 容器，这通常被视为一种反模式。通常您希望将容器限制为Composition Root。见Dependency Injection in .NET。
好吧，它可以与服务定位器模式（我知道，这通常被认为也是反模式）结合使用。我想指出 OP 有更多可能性的事实，DI，不仅仅是构造函数注入。