Liskov替换原理(LSP, LSP)是面向对象编程中的一个概念，它指出:

函数使用指针或 基类的引用必须是 能够使用派生类的对象 在不知不觉中。

LSP的核心是关于接口和契约，以及如何决定何时扩展一个类，还是使用另一种策略(如组合)来实现您的目标。

我所见过的说明这一点的最有效的方法是《Head First OOA&D》。它们呈现的场景是，你是一名致力于为策略游戏构建框架的项目开发者。

他们展示了一个类，它代表一个板子，看起来像这样:

所有的方法都以X和Y坐标作为参数来定位tile在二维tile数组中的位置。这将允许游戏开发者在游戏过程中管理棋盘上的单位。

这本书继续改变了要求，说游戏框架工作也必须支持3D游戏板，以适应有飞行的游戏。因此引入了一个ThreeDBoard类，它扩展了Board。

乍一看，这似乎是个不错的决定。Board提供了高度和宽度属性，ThreeDBoard提供了Z轴。

当你看到从董事会继承的所有其他成员时，它就失效了。AddUnit, GetTile, GetUnits等方法在Board类中都采用X和Y参数，但ThreeDBoard也需要Z参数。

因此，您必须使用Z参数再次实现这些方法。Z参数没有Board类的上下文，从Board类继承的方法失去了意义。试图使用ThreeDBoard类作为其基类Board的代码单元将非常不走运。

也许我们应该另想办法。ThreeDBoard应该由Board对象组成，而不是扩展Board。Z轴上每单位一个板子对象。

这允许我们使用良好的面向对象原则，如封装和重用，并且不违反LSP。

A square is a rectangle where the width equals the height. If the square sets two different sizes for the width and height it violates the square invariant. This is worked around by introducing side effects. But if the rectangle had a setSize(height, width) with precondition 0 < height and 0 < width. The derived subtype method requires height == width; a stronger precondition (and that violates lsp). This shows that though square is a rectangle it is not a valid subtype because the precondition is strengthened. The work around (in general a bad thing) cause a side effect and this weakens the post condition (which violates lsp). setWidth on the base has post condition 0 < width. The derived weakens it with height == width.

因此，可调整大小的正方形不是可调整大小的矩形。

利斯科夫替换原理

(固体)

继承子类型化

维基里斯科夫替换原理(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)

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

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

利斯科夫替换原则(来自Mark Seemann的书)指出，我们应该能够在不破坏客户端或实现的情况下，用另一个接口的实现替换一个接口的实现。正是这一原则使我们能够解决未来出现的需求，即使我们今天不能预见它们。

If we unplug the computer from the wall (Implementation), neither the wall outlet (Interface) nor the computer (Client) breaks down (in fact, if it’s a laptop computer, it can even run on its batteries for a period of time). With software, however, a client often expects a service to be available. If the service was removed, we get a NullReferenceException. To deal with this type of situation, we can create an implementation of an interface that does “nothing.” This is a design pattern known as Null Object,[4] and it corresponds roughly to unplugging the computer from the wall. Because we’re using loose coupling, we can replace a real implementation with something that does nothing without causing trouble.

关于LSP的一个很好的例子(在我最近听到的播客中，Bob叔叔给出了一个例子)是，有时候在自然语言中听起来正确的东西在代码中却不太适用。

在数学中，正方形是长方形。实际上，它是矩形的专门化。“is a”使您想用继承来建模。然而，如果在代码中你从Rectangle派生出Square，那么Square应该可以在任何你想要Rectangle的地方使用。这就导致了一些奇怪的行为。

假设你在你的Rectangle基类上有SetWidth和SetHeight方法;这似乎完全合乎逻辑。然而，如果你的矩形引用指向一个正方形，那么SetWidth和SetHeight没有意义，因为设置一个会改变另一个来匹配它。在这种情况下，Square未能通过矩形的利斯科夫替换测试，并且让Square继承Rectangle的抽象是一个糟糕的抽象。

你们都应该看看其他用励志海报解释的无价的坚实原则。

LSP关注不变量。

经典示例由以下伪代码声明给出(实现略):

class Rectangle {
    int getHeight()
    void setHeight(int value) {
        postcondition: width didn’t change
    }
    int getWidth()
    void setWidth(int value) {
        postcondition: height didn’t change
    }
}

class Square extends Rectangle { }

现在我们有一个问题，尽管接口匹配。原因是我们违反了源自正方形和矩形数学定义的不变量。getter和setter的工作方式，矩形应该满足以下不变量:

void invariant(Rectangle r) {
    r.setHeight(200)
    r.setWidth(100)
    assert(r.getHeight() == 200 and r.getWidth() == 100)
}

然而，Square的正确实现必须违反这个不变量(以及显式后置条件)，因此它不是Rectangle的有效替代品。