3

我有代表同一个业务实体的不同类型的对象。 UIObject, PowershellObject, DevCodeModelObject,WMIObject都是对同一实体的不同表示。

所以说如果实体是Animal那么我有AnimalUIObject, AnimalPSObject, AnimalModelObject,AnimalWMIObject等。

现在AnimalUIObject, AnimalPSObject,的实现AnimalModelObject都在单独的程序集中。

现在我的场景是我想验证业务实体的内容,Animal而不管它来自哪个程序集。所以我创建了一个GenericAnimal类来表示Animal实体。

现在GenericAnimal我添加了以下构造函数:

GenericAnimal(AnimalUIObject)
GenericAnimal(AnimalPSObject)
GenericAnimal(AnimalModelObject)

基本上,我GenericAnimal依赖于所有底层程序集,以便在验证时处理这个抽象。

现在执行此操作的另一种方法是GenericAnimal使用一个空的构造函数,并允许这些底层程序集有一个Transform()方法来构建GenericAnimal.

这两种方法都有一些优点和缺点:

第一种方法:
优点:所有构造逻辑都在一个类中的一个地方GenericAnimal
缺点:GenericAnimal每次有新的表示形式时都必须触及类。

第二种方法:
优点:将构建责任委托给底层组件。
缺点:由于构造逻辑分布在组件中,明天如果我需要添加一个属性XGenericAnimal那么我必须触摸所有组件来更改Transform方法。

哪种方法看起来更好?
或者您认为哪个是较小的邪恶?
有没有比上述两种更好的替代方法?

只是根据我收到的评论进一步阐述。我没有修改底层对象结构的奢侈,即我无法更改 AnimalUIObject AnimalPSObject 等。GenericAnimal 是我仅为验证目的而引入的构造。

4

3 回答 3

4

我认为这两种方法都很“邪恶”。

我认为您真正需要的是从Animal类作为您的核心类开始,并使其余的类包装类使用Animal该类来保存表示。然后针对 Animal API 执行验证。

于 2012-11-17T04:42:34.297 回答
0

可能是抽象工厂模式的机会?

于 2012-11-17T04:44:00.713 回答
0

我有代表同一个业务实体的不同类型的对象。UIObject、PowershellObject、DevCodeModelObject、WMIObject 都是对同一实体的不同表示。

总体上看一下设计模式,特别是结构模式

据我了解,装饰器模式会很有用:

装饰器模式可用于在运行时扩展(装饰)某个对象的功能,独立于同一类的其他实例,前提是在设计时完成了一些基础工作。这是通过设计一个包装原始类的新装饰器类来实现的

所以它应该是第一种方法,但没有缺点:

GenericAnimal 类将有一个构造函数:

GenericAnimal(AnimalObject)

使用AnimalObject接口或抽象类。

缺点:每次有新的表示形式时都必须触及 GenericAnimal 类。

如果您添加另一种表示形式,请使其实现或扩展AnimalObject

于 2012-11-17T05:20:33.093 回答