来自Wikipedia，
Liskov 的行为子类型概念定义了 对象的可替代性；也就是说，如果 S 是 T 的子类型，那么 程序中 T 类型的对象可以被 S 类型的对象替换 在不改变该程序的任何理想属性的情况下（例如 正确性）。
假设如下类层次结构：
AnimalWithFur。它有一个只读属性 furColor，在后继者中被覆盖。Cat，覆盖 furColor 并返回 gray。Tiger，它会覆盖 furColor 并返回 striped。然后我们声明一个带有 Cat 类型参数的方法（not AnimalWithFur）。
向该方法发送Tiger 实例是否违反了 SOLID 中的 L？
【问题讨论】：
标签： oop solid-principles liskov-substitution-principle
严格来说，是的。 Liskov的wiki文章总结说：
“...在一个程序中...不改变那个程序的任何理想属性”
如果您回到 Barbara Liskov 的 original paper，它的措辞字面上更严格，3.3。 类型层次结构：
如果对于每个 S 类型的对象 o1 都有一个 T 类型的对象 o2 使得对于根据 T 定义的所有程序 P，P 的行为不变 当 o1 代替 o2 时
（强调我的）
因此，如果您将 Cat 的一个实例替换为另一个执行不同操作的实例，即返回剥离而不是灰色，那么这在原始意义上是违反 Liskov 的，因为可以轻松定义依赖于颜色的程序是灰色的，在这里：
program(Cat c){
println(c.furColor);
}
如果您将Tiger 传递给该程序而不是Cat，则该程序的行为将改变。
但是，在应用 LSP 的正常方式中，如果您没有添加额外的前置条件或后置条件，则不构成违规。这是一个更实用、更不学术的定义，因为人们接受当用另一种具体类型替换一个具体类型的实例时，您确实打算改变程序的行为，同时保持该程序的理想属性。因此，假设客户端代码可以像处理任何其他颜色一样处理剥离，并且程序的“理想”属性不需要灰色，那么它不会违反。
【讨论】：
简短回答：不一定。根据您提供的信息，我会说不。对我来说，关键是你没有说出想象中的新方法应该做什么。
您可能会认为您在新方法中要求的行为比对类层次结构的关注更重要。
做到这一点的一种方法是从传入的实例/参数中为新方法所需的行为定义一个接口。
然后，您可能想要传递给该方法的任何类都可以实现该接口，并且您可以分解继承层次结构的关注点，并转向关注行为的一致性。
【讨论】：
您的问题很好地描述了为什么使用类组合而不是类继承。首先，您的代码不合逻辑-Tiger 不是您意义上的Cat，Tiger 是Cats family. 之一从代码的角度来看，覆盖并完全替换父类的行为是不好的设计，这实际上是 liskov 替换违规 - 您的 Cat 类意味着定义的 cat 具有一些具体的颜色，并且应用程序希望分别使用它，但是您使用不一致的类型覆盖它并更改行为。
如果你能正确描述类型层次结构，你将有抽象类型 Cat 没有实现 furColor，类型 Tiger 和 HomeCat，但 HomeCat 可以有不同的颜色，不是吗？
如果你想有 LS 违规的简单例子，例如：
您正在使用自定义实现扩展 List 接口，返回大小始终为 10，但内部对象数量不同。每个正常的应用程序都希望使用 for 语句与 list 一起工作，但由于您违反了 LS 原则，并且 List 对象的行为与预期不同。
【讨论】：