我有不同类型的对象代表同一个业务实体。
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是一个仅为我的验证目的而引入的构造。
答案 0 :(得分：4)
我认为这两种方法都很“邪恶”。
我认为你真正需要的是从Animal类开始作为你的核心类，并使用Animal类的其他类包装类来保存表示。然后针对Animal API执行验证。
答案 1 :(得分：0)
可能是抽象工厂模式的机会吗？
答案 2 :(得分：0)
我有不同类型的对象代表相同的业务 实体。 UIObject，PowershellObject，DevCodeModelObject，WMIObject all 是同一实体的不同表示。
一般来看Design Patterns，尤其是Structural Pattern。
根据我的理解，Decorator Pattern会很有用：
装饰器模式可用于扩展（装饰） 运行时某个对象的功能，与其他对象无关 同一类的实例，提供了一些基础工作 设计时间。这是通过设计一个新的装饰器类来实现的 包装原始类
所以它应该是第一种方法，但没有缺点：
GenericAnimal类将有一个构造函数：
GenericAnimal(AnimalObject)
使用AnimalObject接口或抽象类。
缺点：每当有新的时候必须触及GenericAnimal类 表示形式。
如果您添加另一个表示形式，请使其实现或扩展AnimalObject。