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。

LSP是关于类的契约的规则:如果基类满足契约，则LSP派生的类也必须满足该契约。

在Pseudo-python

class Base:
   def Foo(self, arg): 
       # *... do stuff*

class Derived(Base):
   def Foo(self, arg):
       # *... do stuff*

如果每次在派生对象上调用Foo，它给出的结果与在Base对象上调用Foo完全相同，只要arg是相同的。

这里有一个清单来确定你是否违反了利斯科夫法则。

如果你违反了以下项目之一->，你违反了里斯科夫。 如果你不违反任何->不能得出任何结论。

检查表:

No new exceptions should be thrown in derived class: If your base class threw ArgumentNullException then your sub classes were only allowed to throw exceptions of type ArgumentNullException or any exceptions derived from ArgumentNullException. Throwing IndexOutOfRangeException is a violation of Liskov. Pre-conditions cannot be strengthened: Assume your base class works with a member int. Now your sub-type requires that int to be positive. This is strengthened pre-conditions, and now any code that worked perfectly fine before with negative ints is broken. Post-conditions cannot be weakened: Assume your base class required all connections to the database should be closed before the method returned. In your sub-class you overrode that method and left the connection open for further reuse. You have weakened the post-conditions of that method. Invariants must be preserved: The most difficult and painful constraint to fulfill. Invariants are sometimes hidden in the base class and the only way to reveal them is to read the code of the base class. Basically you have to be sure when you override a method anything unchangeable must remain unchanged after your overridden method is executed. The best thing I can think of is to enforce these invariant constraints in the base class but that would not be easy. History Constraint: When overriding a method you are not allowed to modify an unmodifiable property in the base class. Take a look at these code and you can see Name is defined to be unmodifiable (private set) but SubType introduces new method that allows modifying it (through reflection): public class SuperType { public string Name { get; private set; } public SuperType(string name, int age) { Name = name; Age = age; } } public class SubType : SuperType { public void ChangeName(string newName) { var propertyType = base.GetType().GetProperty("Name").SetValue(this, newName); } }

还有2项:方法参数的逆变性和返回类型的协方差。但这在c#中是不可能的(我是c#开发人员)，所以我不关心它们。

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的有效替代品。

它指出，如果C是E的子类型，则E可以替换为C类型的对象，而不会改变或破坏程序的行为。简单地说，派生类应该可以替代它们的父类。例如，如果一个农民的儿子是农民，那么他可以代替他的父亲工作，但如果一个农民的儿子是板球运动员，那么他就不能代替他的父亲工作。

违反的例子:

public class Plane{

  public void startEngine(){}      

}        
public class FighterJet extends Plane{}
    
public class PaperPlane extends Plane{}

在给定的例子中，fighter和PaperPlane类都扩展了包含startEngine()方法的Plane类。所以很明显，战斗机可以启动引擎，但纸飞机不能，所以它破坏LSP。

PaperPlane类虽然扩展了Plane类，但应该可以替代Plane类，但它不是Plane实例可以被替换的合格实体，因为纸飞机不能启动引擎，因为它没有引擎。好的例子是，

受人尊敬的例子:

public class Plane{ 
} 
public class RealPlane{

  public void startEngine(){} 

}
public class FighterJet extends RealPlane{} 
public class PaperPlane extends Plane{}

一些补充:我想知道为什么没有人写基类的不变量、前提条件和后置条件，这些派生类必须遵守。 对于派生类D来说，基类B完全可转换，类D必须服从某些条件:

基类的内变体必须由派生类保留 派生类不能加强基类的先决条件 派生类不能削弱基类的后置条件。

因此派生类必须知道基类施加的上述三个条件。因此，子类型的规则是预先确定的。这意味着，只有当子类型遵守某些规则时，才应该遵守'IS A'关系。这些规则，以不变量、前置条件和后置条件的形式，应该由正式的“设计契约”来决定。

关于这个问题的进一步讨论可以在我的博客:利斯科夫替换原理