c# - 继承:为什么改变一个对象的类型被认为是糟糕的设计？

Question

在对我的域类进行建模时，我发现 Entity Framework 允许您对继承关系进行建模，但不支持将基类型实例提升为其派生类型，即将数据库中现有的 Person 行更改为 Employee，派生来自人。
显然，我不是第一个对此感到疑惑的人，因为这个问题已在 Stack Overflow 上被多次询问和回答(例如，参见 here 和 here)。

如这些答案中所示， Entity Framework 不支持这一点，因为这在面向对象编程中也是不允许的:创建实例后，您无法更改其运行时类型。
很公平，从技术角度来看，我可以理解，一旦为一个对象分配了一个内存块，之后添加一些额外的字节来保存派生类型的字段可能需要重新分配整个内存块，并且结果，将意味着对象的指针现在已经改变，这反过来又引入了更多的问题。所以我知道这很难实现，因此在 C# 中不受支持。

但是，除了技术部分之外，答案(还有 here，请参阅第 1 页的最后一段)似乎也暗示当您需要时它被认为是糟糕的设计更改对象运行时类型，表示您不应该需要这种类型更改，而应该在这些情况下使用组合。

坦率地说，我不明白为什么 - 我想说的是，以与处理 Person 实例相同的方式处理 Employee 实例是完全有效的(即通过从 Person 继承 Employee)，即使在某些时候随着时间的推移，一个人将被聘为雇员，或者一个雇员辞职并重新成为一个人。
从概念上讲，我看不出这有什么问题吗？

谁能给我解释一下？

--编辑，澄清，为什么这被认为是糟糕的设计:

public class Person
{
    public string Name { get; set; }
}

public class Employee: Person
{
    public int EmployeeNr { get; set; }

    public decimal Salary { get; set; }
}

...但这不是吗？

public class Person
{
    public string Name { get; set; }

    public EmployeeInfo EmployeeInfo { get; set; }
}

public class EmployeeInfo
{
    public int EmployeeNr { get; set; }

    public decimal Salary { get; set; }
}

Answer 1

Frankly, I don't get why - I'd say its perfectly valid to want to work Employee instances in the same way as you would with a Person instance (i.e. by inheriting Employee from Person), even if at some point in time a Person will be hired as an Employee, or an Employee quits and becomes a Person again. Conceptually, I don't see anything wrong with this?

我将其理解为 Person -> Employee -> Person？ IE 它仍然是一个人，但他/她/它被归因于“就业”，然后“降级”为一个人？

当 object 在运行时不改变类型时，继承非常有用，例如当你创建一个 equity 对象时，你可以很确定你不想将其转换为 FRA，即使两者都是证券的子类。但是只要在运行时可能会发生某些变化，例如行为，请尝试使用组合。在我之前的示例中，证券子类可能继承自顶级 Assets 类，但是用于将市场值(value)置于 Assets 上的方法应该通过行为模式(例如策略模式)放置在那里，因为您可能希望在一个运行时期间使用不同的方法。

对于您所描述的情况，您不应使用继承。只要有可能，总是倾向于组合而不是继承。如果某些东西在运行时发生了变化，绝对不应该通过继承将它放在那里!

你可以把它比作生命，人生为人死为人，猫生为猫死为猫，某种类型的对象应该被创建为一种类型，垃圾收集也是一样类型。不要通过行为组合来改变事物的本质、行为方式或知识。

我建议你看看Design Patterns: Elements of Reusable Object-Oriented Software其中非常全面地涵盖了一些非常有用的设计模式。