virtual关键字是否本质上违反了Liskov替换原则？

Question

Liskov替换原则指出，您应该编写您的类继承，这样将子类型交换为它们的基类型就不会改变应用程序的行为。

然而，虚拟关键字字面上似乎存在，以允许子类型的行为不同于基类型。虚拟/覆盖关键字（不包括覆盖抽象成员）的大多数使用不可能违反Liskov吗？我觉得这可能比我理解的更微妙。也许这是一个“规则有时会被打破”的情况，或者原则中的“不要有不同的行为”部分有一个灰色地带。

Answer 1

首先，LSP没有说子类型不能改变行为，它说子类型不能改变超类上假设的属性。

引用维基百科：

子类型要求：设（x）是一个关于类型为T的对象x的可证明的属性，那么（y）对于类型为S的对象y应该是真的，其中S是T的子类型。

也就是说，子类型可能不会改变Ф，其中Ф是您可以对超类型做出的任何假设（“可证明属性”）。

第二，如果您的超类有一个virtual方法，并且子类重写它以使其退出程序，那么它是否违反了LSP？只有在调用方不能在超类的方法上假定这一点时。

这意味着，可以很容易地使用虚拟方法编写超类，从而很容易违反LSP。但它不是虚拟的固有属性
然而，该语言可能做得更好的是强制virtual重写至少在其代码中的某个地方调用超类方法。

Answer 2

不幸的是，“视情况而定”。

利斯科夫替代原则（LSP）通常未定义。它应该接受类型可替代性的概念（在类型理论意义上），并将其扩展到行为领域。也就是说，子类型的行为必须“扩展”超级类型的行为。问题在于，它没有很好地定义这些行为是什么，以及如果您正在改变这些行为，您可以如何进行测试。

有许多明显构成违反《法律和社会保障法》的例子。其中大多数都有缺陷，因为它们没有考虑到所有类型替换的先决条件，包括对接口中的方法和类型参数的所有有效的协变和逆变更改都是正确的。LSP是此类型检查的扩展。此外，在签名中使用这种差异的能力是正确实现接口的许多行为的要求，因此满足LSP。

例如，采用Clone（）方法。如果您有一个抽象类哺乳类和一个子类Human，则调用Clone时Human类必须返回Human。这是因为在使用英语单词“Clone”时编码了Clone（）方法的预期行为。将哺乳动物送回违反了预期的行为。

虽然在C#中无法正确实现Clone（）方法，但virtual关键字可以实现“足够接近”的近似值，因此virtual不仅不违反LSP，而且在使用基类时也是必需的。

最后，与SOLID中的所有主体一样，LSP更多地是“代码气味”的集合，而不是实际的可定义规则。他们在那里给你一种讨论为什么代码不好的方式。它不会告诉您代码的真正问题是什么，也不会告诉您如何更正它或如何防止它发生。

Answer 3

引用我自己的话：

传递对象的继承者代替基类不应该破坏被调用方法中的任何现有功能。您应该能够相互替换给定接口的所有实现。

在这里阅读更多我对C#中Liskov替换的想法：https://docs.microsoft.com/en-us/archive/msdn-magazine/2014/may/csharp-best-practices-dangers-of-violating-solid-principles-in-csharp

virtual关键字本身并不是罪魁祸首。is关键字通常是次要Liksov违规的罪魁祸首，因为人们使用它来检查他们的活动实例是否是某个继承者，从而确保行为根据继承而改变。在方法上使用的new关键字更差；见上述文章。