Question

在处理需要实例化大量对象的类时，我总是觉得不舒服，因为我一直在使用依赖注入原则。

例如，假设我有一个应该引发很多不同类型事件的类。每个事件都有不同的类型，所以我要做的是为每个不同的事件类型设置不同的工厂。如果我有10个活动，那么我将需要10个工厂。这看起来不太好。我也可以为所有不同类型的活动设立一个工厂，但这似乎也不太合适。

（对于C＃人群，我不是在谈论.NET的事件。这只是一个例子来说明问题，只是将它们视为常规类！）

这只是一个例子。我在这里或那里有一个工厂没有问题，但在某些项目中，必须在运行时创建大量的对象，似乎我必须为我定义的几乎每个类创建一个工厂！

你如何处理这种情况？我错过了什么吗？

我见过人们只是传递他们使用的IoC容器的引用，但这对我来说似乎没什么好处。 IMO，域模型甚至不知道正在使用IoC容器！

由于

Answer 1

只要我知道DI，我一直是构造函数注入的粉丝，因为在我看来，构造函数是。它声明“我需要以下类/接口的实例才能完成我的工作” - 例如给我一个File和PrintWriter，我会把前者的内容写给后者。

当然，这意味着代码不了解DI框架，因为该类正在构建时传递了所需的依赖项。另外，我认为在这种情况下不需要工厂，因为类是通过构造函数自己的工厂。

至于你在第二段中确定的场景，我不确定这是否与依赖注入严格相关，而只是设计了类层次结构和职责。要么，您的班级明确知道如何创建与{1}相对应的Event。登录失败，在这种情况下它会这样做（即通过调用类的构造函数）; 或，它不知道如何处理，在这种情况下，它必须委托某些种类的工厂来创建Event。

在这种情况下，您可以设置您的类以使用相同的工厂来创建所有十个事件（使用10个方法定义EventFactory接口），或者您可以定义单独的工厂接口（＆amp; implementation）对于需要构建的每种类型的事件。在后一种情况下，您还需要在主类的构造函数中传入十个不同的工厂。

但是再一次 - 这与DI恕我直言没有关系，这是一个关于你如何设计你的类的灵活性（或“企业性”）与直接性的问题。在我看来，这两者是正交的;首先定义您的类需要哪些协作者（十个工厂，一个工厂或零工厂），然后然后使用DI来提供这些依赖关系。 DI的存在或其他方面不应影响您的课堂设计。

Answer 2

实例化许多其他对象的类没有任何问题。相反，该类应被视为aggregate root域实体。对于实体的不同“类型”，如果您假设它们实现相同的接口或从同一基类继承，那么将type参数传递给Factory.create(type)是我通常如何处理此问题。 create()的内部可以将策略模式委托给其他类，但面向API的客户端很简单。

现在如果你正在为你正在处理的每个班级创建一个工厂，那听起来就像反模式。研究上面提到的聚合根模式，看看你是否可以将实体组织成图形 - 你应该能够 - 这样一个工厂就足以生成整个图形。

对于IoC，域模型不应该知道容器。当我的实体需要在容器中引用单身人士（通常是工厂）时，我通常会将一个工厂注入另一个工厂：

class FactoryA {
    void setFactoryB(FactoryB factoryB) { /* sets into state */ }
    EntityA create(Enum type) {
        EntityA entityA = new EntityA();
        /* DI FactoryB - this method is probably default access */
        entityA.setFactoryB(getFactoryB());
    }
}

class FactoryB {}

因此，在上面的示例中，FactoryA和FactoryB都是由IoC容器管理的单例。 EntityA需要引用FactoryB，因此FactoryA会引用FactoryB方法中传递的create()。

依赖注入导致工厂扩散？

2 个答案: