自从我一直使用依赖注入原理以来,在处理需要实例化许多对象的类时,我总是感到不舒服。
例如,假设我有一个班级应该引发许多不同类型的事件。每个事件都有不同的类型,所以我要做的是为每个不同的事件类型使用不同的工厂。如果我有10个活动,那么我将必须有10个工厂。那似乎不太好。我也可以为所有不同类型的事件建立一个工厂,但这似乎也不是很正确。
(对于C#人群,我在这里不是在谈论.NET的事件。这只是一个例子,可以将它们视为常规类!)
这只是一个例子。我在这里或那里建立工厂没有问题,但是在某些类型的项目中,必须在运行时创建很多对象,似乎我必须为定义的几乎每个类都建立工厂!
您如何处理这种情况?我想念什么吗?
我见过人们只是绕过他们使用的IoC容器的引用,但这对我来说似乎没有任何好处。IMO,域模型甚至都不应该知道正在使用IoC容器!
谢谢
实例化许多其他对象的类没有错。相反,该类应被视为聚合的根域实体。至于实体的不同“类型”,如果您假设它们实现相同的接口或从相同的基类继承,则通常将我传递给该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()
方法内部传递的引用。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句