dev*_*ium 7 c# java oop dependency-injection factory-pattern
在处理需要实例化大量对象的类时,我总是觉得不舒服,因为我一直在使用依赖注入原则.
例如,假设我有一个应该引发很多不同类型事件的类.每个事件都有不同的类型,所以我要做的是为每个不同的事件类型设置不同的工厂.如果我有10个活动,那么我将需要10个工厂.这看起来不太好.我也可以为所有不同类型的活动设立一个工厂,但这似乎也不太合适.
(对于C#人群,我不是在谈论.NET的事件.这只是一个例子来说明问题,只需将它们视为常规类!)
这只是一个例子.我在这里或那里有一个工厂没有问题,但在某些项目中,必须在运行时创建大量的对象,似乎我必须为我定义的几乎每个类创建一个工厂!
你是如何处理这种情况的？我错过了什么吗？
我见过人们只是传递他们使用的IoC容器的引用,但这对我来说似乎没什么好处.IMO,域模型甚至不知道正在使用IoC容器!
谢谢
只要我知道DI,我一直是构造函数注入的粉丝,因为在我看来这就是构造函数的用途.它声明"我需要以下类/接口的实例来完成我的工作" - 例如,传递给我一个File和一个PrintWriter,我将把前者的内容写入后者.
当然,这意味着代码不了解DI框架,因为类正在构建时传递了所需的依赖项.另外,我认为在这种情况下不需要工厂,因为类是通过构造函数自己的工厂.
至于你在第二段中确定的场景,我不确定这是否与依赖注入严格相关,而只是设计了类层次结构和职责. 要么你的类具体知道如何创建一个Event对应于例如失败的登录,在这种情况下它会这样做(即通过调用类的构造函数); 或者,它不知道如何,在这种情况下,它将委托给某种工厂来创建Event.
在这种情况下,您可以设置您的类以使用相同的工厂来创建所有十个事件(EventFactory使用10个方法定义接口),或者您可以为需要构造的每种类型的事件定义单独的工厂接口(和实现).在后一种情况下,您还需要在主类的构造函数中传入十个不同的工厂.
但是再一次 - 这与DI恕我直言无关,这是一个关于如何设计灵活性(或"企业性")与直接性的类的问题.在我看来,这两者是正交的; 首先定义您的类所需的协作者(十个工厂,一个工厂或零工厂),然后使用DI来提供这些依赖关系.DI的存在或其他方面不应影响您的课堂设计.
一个类实例化许多其他对象并没有什么问题。相反，该类应被视为聚合根域实体。至于不同“类型”的实体，如果您假设它们实现相同的接口或从相同的基类继承，那么传递参数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()。