在基类中声明子类型；是坏还是不好？

Question

最近我遇到了一些将子类型声明为基类中的枚举的代码。这是一个简单的例子：

public enum EmployeeType
{
    Manager,
    Secretary
}

public class Employee
{
    public string Code { get; set; }

    public EmployeeType Type { get; set; }
}

public class Manager : Employee
{
    public void Manage()
    {
        // Managing
    }
}

public class Secretary : Employee
{
    public void SetMeeting()
    {
        // Setting meeting
    }
}

根据我的开发经验，我写了an article 关于它，声明这是一个糟糕的实践/设计。我认为这很糟糕，因为基类应该对其子类不可知。它应该没有关于其子类的信息，这至少有两个原因：

1. 可扩展性：此设计不可扩展，因为如果您想定义另一个派生类，例如Developer，您还应该更新您可能无权访问的EmployeeType 枚举。

2. 自相矛盾的定义：现在你可以写这段代码了：

   Secretary secretary = new Secretary();
   secretary.EmployeeType = EmployeeType.Manager;
   /*
   This is absurd semantically. But syntactically, it's possible.
   */
   

但是，当我阅读Wikipedia's article about inheritance 时，我找不到任何问题的答案。

虽然乍一看可能有争议，但我相信继承应该足够成熟，可以为这个困境提供可靠的答案。这段代码不好吗，smelly code？还是可以接受和合理的？为什么？

Answer 1

我认为当我们回到什么时候使用继承的哲学时问题就可以解决了。
据说“把继承看成一个是一个 关系”

当您在两个类之间建立继承关系时，您可以利用动态绑定和多态性。
动态绑定表示在运行时根据类调用哪个方法实现
多态性意味着您可以使用超类类型的变量来保存对其类是超类或其任何子类的对象的引用。

动态绑定和多态性的主要好处之一是它们可以帮助使代码更容易更改。如果您的代码片段使用了超类类型的变量，例如 Employee，您可以稍后创建一个全新的子类，例如 Manager，并且旧代码片段将在不更改新子类实例的情况下工作。如果 Manager 覆盖了代码片段调用的任何 Employee 方法，动态绑定将确保 Managers 对这些方法的实现得到执行。即使在编写和编译代码片段时类管理器不存在也是如此。

现在回到问题，为什么我们需要 Employee 中的 EmployeeType？
我们可能想在 Employee 中实现一些函数，AKA CalculateSalary()

CalculateSalary(){
if (EmployeeType == EmployeeType.Manager) // Add management percent }

诱人的理由，但如果员工既是经理又是主管怎么办？
它会很复杂！简单地说，我们可以将 CalculateSalary() 实现为抽象方法，但我们将失去目标！
这是 Coad 的规则：
子类表示是一种特殊的，而不是一种所扮演的角色。
Liskov Substitution 原则是测试“我是否应该从这种类型继承” ?'

以上拇指的作用是：

• TypeB 是否要公开完整的接口（所有公共方法 不少于）的TypeA，这样TypeB可以在TypeA所在的地方使用 预期的？表示继承。
  例如塞斯纳双翼飞机将暴露 飞机的完整界面，如果不是更多的话。所以这使得它 适合从飞机派生。
• TypeB 是否只需要 TypeA 公开的部分/部分行为？ 表示需要组合。
  例如一只鸟可能只需要苍蝇 飞机的行为。在这种情况下，提取它是有意义的 作为接口/类/两者并使其成为两者的成员 类。
  

作为javaworld的脚注：
确保继承对 is-a 关系建模。
不要仅仅为了代码重用而使用继承。
不要仅仅为了获得多态性而使用继承。
优先考虑组合而不是继承。

我认为在这样的场景中，作为经理是员工扮演的角色，这个角色可能会随着时间的推移而改变，这个角色将作为一个组合来实现。

作为领域模型的另一个方面，并将其映射到关系数据库。将继承映射到 SQL 模型真的很困难（您最终会创建不总是使用的列，使用视图等）。一些 ORM 试图解决这个问题，但它总是很快变得复杂。
例如 Hibernate 的 One Table Per Class Hierarchy 方法，它违反了2NF 并且很可能导致您的样本不一致 p>

Secretary secretary = new Secretary();
secretary.EmployeeType = EmployeeType.Manager;

Answer 2

我认为它对于某些场景来说是一个很好的设计，而且它肯定是在 .NET 基类库的各个部分中反复出现的模式。

我认为暗示它可能是糟糕设计的误解是类层次结构必须是可扩展的。然而，最重要的是，继承关系只是表达了某些子类型是超类型的特化，并且子类型与超类型不同，但与超类型（接口）兼容。

通过继承相关的一系列类型不一定为第三方添加任何其他类型提供任何可能性。当此类类型族表示标准中定义的数据结构时，通常会出现这种情况，但并非唯一。

至于用enum 值表示当前类的类型，如果继承层次仅限于第三方扩展，则没有什么反对的。严格来说，这样的属性不应该是必要的，但由于 C# 等语言不提供任何类型切换的可能性，提供 enum 值可以提高必须处理不同类型的代码的可读性类型族的类型，因此构成了良好的 API 设计。在这方面，它还提高了可维护性，因为同一类型系列的未来版本可能会重新构建类型层次结构。专门检查 enum 值的代码将与此类更改无关（以及容易出错的解决方法，例如检查 (string) 类型名称而不是 Type 对象本身将不会首先引入)。

.NET BCL 在很多地方使用这种模式，例如：

• XmlNode 与 XmlNodeType
• XObject 和 XmlNodeType
• Expression 和 ExpressionType
• MemberInfo 与 MemberType

Answer 3

这绝对是不好的做法。撇开对继承的可疑使用（与使用组合相比，这本身被广泛认为是不好的做法），它通过在父类和子类之间引入令人讨厌的循环依赖来打破Dependency inversion principle。

在重新设计代码时，我希望解决三个问题：

1. 我会通过从基类中删除枚举来删除循环依赖。
2. 我会让 Employee 成为一个接口。
3. 我会考虑删除公共设置器，它允许应用程序的任何方面修改员工记录的核心方面，从而使测试和跟踪错误比他们需要的要困难得多。

Answer 4

我同意这是不好的做法，但在某些情况下，这可能是必要的或有用的，如果是这样，您至少可以通过将基类的属性设置为只读并通过子类。

public enum EmployeeType
{
    Manager,
    Secretary
}

public class Employee
{
    public Employee(EmployeeType type)
    {
        this.Type = type;
    }

    public string Code { get; set; }

    public EmployeeType Type { get; private set; }
}

public class Manager : Employee
{
    public Manager()
        : base(EmployeeType.Manager)
    {
    }

    public void Manage()
    {
        // Managing
    }
}

public class Secretary : Employee
{
    public Secretary()
        : base(EmployeeType.Secretary)
    {
    }

    public void SetMeeting()
    {
        // Setting meeting
    }
}

为防止 Employee 被错误的类型实例化，您可以将其设置为受保护的。

一般来说，这个问题非常广泛，这意味着它实际上取决于整体设计，我会尝试通过重构/重新设计期望 Type 属性的类结构和/或逻辑来防止这种情况发生。

Answer 5

这听起来很糟糕的“代码味道”，我会说糟糕的设计。但我通常会做这样的事情，但我觉得这是可以接受的。

public enum EmployeeType
{
    UnKnown,//this can be used for extensiblity
    Manager,
    Secretary,    
}

public abstract class Employee//<--1
{
    public string Code { get; set; }

    public abstract EmployeeType Type { get; } //<--2
}

public class Manager : Employee
{
    public override EmployeeType Type { get { EmployeeType.Manager; } }//<--3
    public void Manage()
    {
        // Managing
    }
}

public class Secretary : Employee
{
    public override EmployeeType Type { get { EmployeeType.Secretary; } }//<--4
    public void SetMeeting()
    {
        // Setting meeting
    }
}

然后是它的工厂..

EmployeeFactory.Create(employeeType);

我对您的原始代码进行了“4”次更改，现在它看起来有点“工厂模式”。可能是代码作者理解“工厂模式”错误。但是谁知道呢？