简单来说，LSP是指同一超类的对象应该能够在不破坏任何东西的情况下相互交换。

例如，如果我们有一个从Animal类派生的Cat和Dog类，那么任何使用Animal类的函数都应该能够使用Cat或Dog，并且行为正常。

使用指向基类的指针或引用的函数必须能够在不知道它的情况下使用派生类的对象。

当我第一次阅读LSP时，我认为这是一个非常严格的含义，本质上等同于接口实现和类型安全强制转换。这意味着语言本身要么保证LSP，要么不保证LSP。例如，在严格意义上，ThreeDBoard当然可以取代Board，就编译器而言。

在阅读了更多关于LSP的概念之后，我发现LSP的解释通常比这更广泛。

简而言之，对于客户端代码来说，“知道”指针后面的对象是派生类型而不是指针类型的含义并不仅限于类型安全。对LSP的遵守也可以通过探测对象的实际行为进行测试。也就是说，检查对象的状态和方法参数对方法调用结果或从对象抛出的异常类型的影响。

再次回到示例，理论上Board方法可以在ThreeDBoard上很好地工作。然而，在实践中，在不妨碍ThreeDBoard打算添加的功能的情况下，防止客户端可能无法正确处理的行为差异是非常困难的。

掌握了这些知识后，评估LSP粘附性可以成为一个很好的工具，可以确定何时组合机制更适合扩展现有功能，而不是继承。

我在每个答案中都看到了矩形和正方形，以及如何违反LSP。

我想用一个真实的例子来展示LSP是如何符合的:

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return $result; 
    }
}

这种设计符合LSP，因为无论我们选择使用哪种实现，行为都不会改变。

是的，你可以在这个配置中违反LSP，做一个简单的改变，像这样:

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return ['result' => $result]; // This violates LSP !
    }
}

现在子类型不能以同样的方式使用，因为它们不再产生相同的结果。

利斯科夫替换原理

(固体)

继承子类型化

维基里斯科夫替换原理(LSP)

在子类型中不能加强先决条件。 后置条件不能在子类型中减弱。 超类型的不变量必须保留在子类型中。

子类型不应该要求调用者提供比超类型更多的(先决条件) 子类型不应该为小于超类型的调用者公开(后置条件)

*前置条件+后置条件=函数(方法)类型[Swift函数类型。Swift函数与方法

//Swift function
func foo(parameter: Class1) -> Class2

//function type
(Class1) -> Class2

//Precondition
Class1

//Postcondition
Class2

例子

//C3 -> C2 -> C1

class C1 {}
class C2: C1 {}
class C3: C2 {}

前提条件(如。函数参数类型)可以相同或更弱(力求-> C1) 后置条件(如。函数返回类型)可以相同或更强(力求-> C3) 超类型的不变变量[About]应该保持不变

斯威夫特

class A {
    func foo(a: C2) -> C2 {
        return C2()
    }
}

class B: A {
    override func foo(a: C1) -> C3 {
        return C3()
    }
}

Java

class A {
    public C2 foo(C2 a) {
        return new C2();
    }
}

class B extends A {
    @Override
    public C3 foo(C2 a) { //You are available pass only C2 as parameter
        return new C3();
    }
}

行为子类型化

维基里斯科夫替换原理(LSP)

子类型中方法参数类型的逆变性。子类型中方法返回类型的协方差。 子类型中的方法不能引发新的异常，除非它们是超类型的方法引发的异常的子类型。

[方差，协方差，逆变，不变性]

以Board数组的形式实现ThreeDBoard会有用吗?

也许你想把不同平面上的ThreeDBoard切片作为一个板。在这种情况下，您可能希望为Board抽象出一个接口(或抽象类)，以允许多种实现。

就外部接口而言，您可能希望为TwoDBoard和ThreeDBoard提取一个Board接口(尽管上述方法都不适合)。

大局:

利斯科夫替换原理是什么?它是关于什么是(什么不是)给定类型的子类型。 为什么它如此重要?因为子类型和子类之间是有区别的。

例子

与其他答案不同的是，我不会从违反Liskov替换原则(LSP)开始，而是从符合LSP开始。我使用Java，但在每种OOP语言中几乎都是一样的。

圆和彩色圆

几何例子在这里似乎很流行。

class Circle {
    private int radius;

    public Circle(int radius) {
        if (radius < 0) {
            throw new RuntimeException("Radius should be >= 0");
        }
        this.radius = radius;
    }

    public int getRadius() {
        return this.radius;
    }
}

半径不允许为负。这是一个子类:

class ColoredCircle extends Circle {
    private Color color; // defined elsewhere

    public ColoredCircle(int radius, Color color) {
        super(radius);
        this.color = color;
    }

    public Color getColor() {
        return this.color;
    }
}

从LSP来看，这个子类是Circle的子类型。

LSP的状态为:

如果对于类型S的每个对象o1，都有一个类型T的对象o2，使得对于所有用T定义的程序P，当o1取代o2时，P的行为不变，那么S是T的子类型(Barbara Liskov，“数据抽象和层次结构”，SIGPLAN通知，23,5(1988年5月))。

这里，对于每个ColoredCircle实例o1，考虑Circle实例具有相同的半径o2。对于每个使用Circle对象的程序，如果您将o2替换为o1，则任何使用Circle的程序的行为在替换之后都将保持不变。(注意，这只是理论上的:使用ColoredCircle实例会比使用Circle实例更快地耗尽内存，但这与本文无关。)

我们如何根据o1求出o2 ?我们只是去掉color属性，保留radius属性。我称这个变换为o1 - >o2是CircleColor空间在Circle空间上的投影。

反例

让我们再创建一个例子来说明LSP的违反。

圆形和方形

想象一下前面Circle类的子类:

class Square extends Circle {
    private int sideSize;

    public Square(int sideSize) {
        super(0);
        this.sideSize = sideSize;
    }

    @Override
    public int getRadius() {
        return -1; // I'm a square, I don't care
    }

    public int getSideSize() {
        return this.sideSize;
    }
}

LSP违反

现在，看看这个程序:

public class Liskov {
    public static void program(Circle c) {
        System.out.println("The radius is "+c.getRadius());
    }

我们用一个Circle对象和一个Square对象测试程序。

    public static void main(String [] args){
        Liskov.program(new Circle(2)); // prints "The radius is 2"
        Liskov.program(new Square(2)); // prints "The radius is -1"
    }
}

发生了什么事?直观地说，虽然Square是Circle的一个子类，但Square不是Circle的子类型，因为没有一个常规的Circle实例的半径是-1。

形式上，这违反了利斯科夫替换原则。

我们有一个用Circle定义的程序，在这个程序中没有Circle对象可以替换新的Square(2)(顺便说一下，也没有任何Square实例)，并且保持行为不变:记住，任何Circle的半径总是正的。

子类和子类型

现在我们知道为什么子类并不总是子类型。当子类不是子类型时，即存在LSP违反时，某些程序(至少有一个)的行为并不总是预期的行为。这是非常令人沮丧的，通常被解释为一个错误。

在理想的情况下，编译器或解释器将能够检查给定的子类是否是真正的子类型，但我们并不是在理想的情况下。

静态类型

如果存在一些静态类型，则在编译时被父类签名绑定。Square.getRadius()不能返回String或List。

如果没有静态类型，如果一个参数的类型是错误的(除非类型是弱的)或参数的数量不一致(除非语言是非常允许的)，您将在运行时得到一个错误。

关于静态类型的注意:有返回类型的协方差(S的方法可以返回T的相同方法的返回类型的子类)和参数类型的逆变性(S的方法可以接受T的相同方法的相同参数的超类)的机制，这是下面解释的先决条件和后置条件的具体情况。

合同设计

有更多的。有些语言(我想到了Eiffel)提供了一种机制来强制执行LSP。

先不说确定初始对象o1的投影o2，如果用o1代替o2 if，对于任何参数x和任何方法f，我们可以期望任何程序都有相同的行为:

如果o2.f(x)是一个有效调用，那么o1.f(x)也应该是一个有效调用(1)。 o1.f(x)的结果(返回值，在控制台上显示等)应该等于o2.f(x)的结果，或者至少同样有效(2)。 o1.f(x)应该让o1处于内部状态，o2.f(x)应该让o2处于内部状态，这样下一次函数调用将确保(1)，(2)和(3)仍然有效(3)。

(注意，如果函数f是纯函数，则(3)是免费给出的。这就是为什么我们喜欢使用不可变对象。)

这些条件是关于类的语义(期望什么)，而不仅仅是类的语法。而且，这些条件非常强。但是它们可以用契约式编程设计中的断言来近似。这些断言是确保支持类型语义的一种方法。破坏契约会导致运行时错误。

前提条件定义了什么是有效的调用。当子类化一个类时，前提条件只能被削弱(S.f接受的比T.f多)(a)。 后置条件定义了什么是有效结果。当子类化一个类时，后置条件只能被加强(S.f比T.f提供更多)(b)。 不变量定义了什么是有效的内部状态。当子类化一个类时，不变量必须保持不变(c)。

我们可以大致看到，(a)保证了(1)，(b)保证了(2)，但是(c)比(3)弱。此外，断言有时难以表达。

假设一个类Counter有一个唯一的方法Counter. Counter()，该方法返回下一个整数。怎么写后置条件呢?假设一个类Random有一个方法Random.高斯()，该方法返回一个介于0.0和1.0之间的浮点数。如何编写后置条件来检查分布是否为高斯分布?这也许是可能的，但成本太高，我们将依赖于测试而不是后置条件。

结论

不幸的是，子类并不总是子类型。这可能会导致意想不到的行为——bug。

面向对象语言提供了避免这种情况的机制。首先在语法层面。在语义层面上也是如此，这取决于编程语言:可以使用断言在程序文本中编码一部分语义。但是，由您来确保子类是子类型。

还记得你什么时候开始学习OOP吗?“如果关系是is - a，那么使用继承”。另一种方式也是如此:如果使用继承，请确保关系是is - a。

LSP在比断言更高的级别上定义了什么是子类型。断言是确保LSP得到维护的有价值的工具。