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每次有新的表示形式时都必须触及类。

第二种方法：
优点：将构建责任委托给底层组件。
缺点：由于构造逻辑分布在组件中，明天如果我需要添加一个属性X，GenericAnimal那么我必须触摸所有组件来更改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 回答