c# - 继承与类型标志

Question

我已经做了一些搜索(也许我没有很好地描述我的问题)但是没能找到这个问题的答案

假设您有以下 POCO:

public class StandardObject
{
   public string A {get;set;}
   public string B {get;set;}
}

程序中的其他地方有一些处理标准对象的逻辑。存在有时可能需要以不同方式处理 StandardObject 的情况。我们在创建 StandardObject 时就知道这一点，但是当前的任何属性都不能用于进一步确定链中的这一点。一种方法是在 StandardObject 上添加和设置标志或类型枚举，并在处理对象时检查它。例如

if(standardObject.IsSpecial){...}

if(standardObject.ObjectType == StandardObjectTypeEnum.Special){...}

但这似乎不是最好的方法。

另一种选择是创建派生类:

public class SpecialObject : StandardObject { }

所以现在我们可以检查类型而不是检查属性。例如

if(standardObject.GetType() == typeof(SpecialObject)){...}

(根据我们所做的，类型检查的实现可能不同)

请注意，SpecialObject 不会以任何方式添加或更改 StandardObject。它本质上是同一个对象。这种方法的优点是更灵活(例如，我们可以向 SpecialObject 添加一些额外的属性)但实际上它不会改变。它将始终相同。

对我来说，继承似乎是更好的方法。类型标志看起来像是代码的味道，而继续继承似乎更像是正确的 OOP 方法。我在这里不确定的是，鉴于 StandardObject 和 SpecialObject 是相同的，这样做是不是不好的做法？或者有什么理由应该避免这种情况？

这里有一个类似的问题:

Chess piece hierarchy design: inheritance vs type fields

然而，大多数讨论似乎都集中在国际象棋问题上，而不是什么才是好的设计

编辑:

封装似乎是流行的解决方案。我避免封装的原因在下面的示例中得到了最好的描述:

• StandardObject 本质上是一个 DTO
• 有一个 StandardObject 列表。
• 处理列表，序列化 StandardObject
• 序列化数据通过任意数量的不同协议(protocol)发送到某处
• 如果 StandardObject 是“特殊的”，其中一个协议(protocol)需要设置某些参数

鉴于“特殊”情况的附加逻辑仅被处理 StandardObject 的许多不同机制之一所需要，因此该逻辑似乎不属于 StandardObject 附近的任何地方

Answer 1

它们都是代码味道。如果您有必须在两个相关类型之间以不同方式完成的特殊处理，请让它们都实现一些虚拟方法或接口(interface)操作，以允许它们处理特殊情况(如果没有必要，则不实现)。