该原则由Barbara Liskov在1987年提出，并通过关注超类及其子类型的行为来扩展开闭原则。

当我们考虑违反它的后果时，它的重要性就变得显而易见了。考虑一个使用以下类的应用程序。

public class Rectangle 
{ 
  private double width;

  private double height; 

  public double Width 
  { 
    get 
    { 
      return width; 
    } 
    set 
    { 
      width = value; 
    }
  } 

  public double Height 
  { 
    get 
    { 
      return height; 
    } 
    set 
    { 
      height = value; 
    } 
  } 
}

想象一下，有一天，客户要求除了矩形之外还能操作正方形。因为正方形是矩形，所以square类应该派生自rectangle类。

public class Square : Rectangle
{
} 

然而，这样做会遇到两个问题:

一个正方形不需要从矩形继承高度和宽度变量，如果我们必须创建成千上万个正方形对象，这可能会造成严重的内存浪费。 从矩形继承的width和height setter属性不适用于正方形，因为正方形的宽度和高度是相同的。 为了将height和width设置为相同的值，我们可以创建两个新属性，如下所示:

public class Square : Rectangle
{
  public double SetWidth 
  { 
    set 
    { 
      base.Width = value; 
      base.Height = value; 
    } 
  } 

  public double SetHeight 
  { 
    set 
    { 
      base.Height = value; 
      base.Width = value; 
    } 
  } 
}

现在，当有人设置一个正方形物体的宽度时，它的高度将相应地改变，反之亦然。

Square s = new Square(); 
s.SetWidth(1); // Sets width and height to 1. 
s.SetHeight(2); // sets width and height to 2. 

让我们继续考虑另一个函数:

public void A(Rectangle r) 
{ 
  r.SetWidth(32); // calls Rectangle.SetWidth 
} 

如果我们将一个方形对象的引用传递给这个函数，我们将违反LSP，因为该函数对其参数的导数不起作用。属性width和height不是多态的，因为它们在矩形中没有被声明为虚的(正方形对象将被损坏，因为高度不会被改变)。

然而，通过将setter属性声明为virtual，我们将面临另一个违反，即OCP。事实上，派生类正方形的创建会导致基类矩形的变化。

罗伯特·马丁有一篇关于利斯科夫替换原理的优秀论文。它讨论了可能违反原则的微妙和不那么微妙的方式。

论文的一些相关部分(注意，第二个例子被大量压缩):

A Simple Example of a Violation of LSP One of the most glaring violations of this principle is the use of C++ Run-Time Type Information (RTTI) to select a function based upon the type of an object. i.e.: void DrawShape(const Shape& s) { if (typeid(s) == typeid(Square)) DrawSquare(static_cast<Square&>(s)); else if (typeid(s) == typeid(Circle)) DrawCircle(static_cast<Circle&>(s)); } Clearly the DrawShape function is badly formed. It must know about every possible derivative of the Shape class, and it must be changed whenever new derivatives of Shape are created. Indeed, many view the structure of this function as anathema to Object Oriented Design. Square and Rectangle, a More Subtle Violation. However, there are other, far more subtle, ways of violating the LSP. Consider an application which uses the Rectangle class as described below: class Rectangle { public: void SetWidth(double w) {itsWidth=w;} void SetHeight(double h) {itsHeight=w;} double GetHeight() const {return itsHeight;} double GetWidth() const {return itsWidth;} private: double itsWidth; double itsHeight; }; [...] Imagine that one day the users demand the ability to manipulate squares in addition to rectangles. [...] Clearly, a square is a rectangle for all normal intents and purposes. Since the ISA relationship holds, it is logical to model the Square class as being derived from Rectangle. [...] Square will inherit the SetWidth and SetHeight functions. These functions are utterly inappropriate for a Square, since the width and height of a square are identical. This should be a significant clue that there is a problem with the design. However, there is a way to sidestep the problem. We could override SetWidth and SetHeight [...] But consider the following function: void f(Rectangle& r) { r.SetWidth(32); // calls Rectangle::SetWidth } If we pass a reference to a Square object into this function, the Square object will be corrupted because the height won’t be changed. This is a clear violation of LSP. The function does not work for derivatives of its arguments. [...]

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

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

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

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

当一些代码认为它正在调用类型T的方法时，LSP是必要的，并且可能在不知情的情况下调用类型S的方法，其中S扩展了T(即S继承、派生于超类型T，或者是超类型T的子类型)。

例如，当一个函数的输入形参类型为T时，调用(即调用)的实参值类型为S。或者，当一个类型为T的标识符被赋值类型为S时，就会发生这种情况。

val id : T = new S() // id thinks it's a T, but is a S

LSP要求T类型方法(例如Rectangle)的期望(即不变量)，当调用S类型方法(例如Square)时不违反此期望。

val rect : Rectangle = new Square(5) // thinks it's a Rectangle, but is a Square
val rect2 : Rectangle = rect.setWidth(10) // height is 10, LSP violation

即使是具有不可变字段的类型仍然有不变量，例如，不可变的矩形设置器期望维度被独立修改，但不可变的正方形设置器违背了这一期望。

class Rectangle( val width : Int, val height : Int )
{
   def setWidth( w : Int ) = new Rectangle(w, height)
   def setHeight( h : Int ) = new Rectangle(width, h)
}

class Square( val side : Int ) extends Rectangle(side, side)
{
   override def setWidth( s : Int ) = new Square(s)
   override def setHeight( s : Int ) = new Square(s)
}

LSP要求子类型S的每个方法必须有逆变的输入参数和协变的输出。

逆变是指方差与继承方向相反，即子类型S的每个方法的每个输入参数的Si类型必须与超类型T的相应方法的相应输入参数的Ti类型相同或为超类型。

协方差是指子类型S的每个方法的输出的方差在继承的同一方向，即类型So，必须是超类型T的相应方法的相应输出的相同或类型To的子类型。

这是因为如果调用者认为它有一个类型T，认为它正在调用一个类型T的方法，那么它就会提供类型Ti的参数，并将输出分配给类型to。当它实际调用S的对应方法时，每个Ti输入参数被赋值给Si输入参数，So输出被赋值给类型to。因此，如果Si与Ti的w.r.t.不是逆变的，那么就可以将Si的子类型xi赋给Ti，而它不是Si的子类型。

此外，对于在类型多态性参数(即泛型)上具有定义-站点方差注释的语言(例如Scala或Ceylon)，类型T的每个类型参数的方差注释的共方向或反方向必须分别与具有类型参数类型的每个输入参数或输出(T的每个方法)的方向相反或相同。

此外，对于每个具有函数类型的输入参数或输出，所需的方差方向是相反的。该规则是递归应用的。

子类型适用于可以枚举不变量的地方。

关于如何对不变量建模，以便由编译器强制执行，有很多正在进行的研究。

Typestate (see page 3) declares and enforces state invariants orthogonal to type. Alternatively, invariants can be enforced by converting assertions to types. For example, to assert that a file is open before closing it, then File.open() could return an OpenFile type, which contains a close() method that is not available in File. A tic-tac-toe API can be another example of employing typing to enforce invariants at compile-time. The type system may even be Turing-complete, e.g. Scala. Dependently-typed languages and theorem provers formalize the models of higher-order typing.

Because of the need for semantics to abstract over extension, I expect that employing typing to model invariants, i.e. unified higher-order denotational semantics, is superior to the Typestate. ‘Extension’ means the unbounded, permuted composition of uncoordinated, modular development. Because it seems to me to be the antithesis of unification and thus degrees-of-freedom, to have two mutually-dependent models (e.g. types and Typestate) for expressing the shared semantics, which can't be unified with each other for extensible composition. For example, Expression Problem-like extension was unified in the subtyping, function overloading, and parametric typing domains.

我的理论立场是，对于知识的存在(见章节“集中化是盲目的和不合适的”)，永远不会有一个通用模型可以在图灵完备的计算机语言中强制100%覆盖所有可能的不变量。要让知识存在，就必须存在许多意想不到的可能性，即无序和熵必须总是在增加。这是熵力。证明一个潜在扩展的所有可能的计算，就是计算一个先验的所有可能的扩展。

This is why the Halting Theorem exists, i.e. it is undecidable whether every possible program in a Turing-complete programming language terminates. It can be proven that some specific program terminates (one which all possibilities have been defined and computed). But it is impossible to prove that all possible extension of that program terminates, unless the possibilities for extension of that program is not Turing complete (e.g. via dependent-typing). Since the fundamental requirement for Turing-completeness is unbounded recursion, it is intuitive to understand how Gödel's incompleteness theorems and Russell's paradox apply to extension.

对这些定理的解释将它们纳入对熵力的广义概念理解中:

Gödel's incompleteness theorems: any formal theory, in which all arithmetic truths can be proved, is inconsistent. Russell's paradox: every membership rule for a set that can contain a set, either enumerates the specific type of each member or contains itself. Thus sets either cannot be extended or they are unbounded recursion. For example, the set of everything that is not a teapot, includes itself, which includes itself, which includes itself, etc…. Thus a rule is inconsistent if it (may contain a set and) does not enumerate the specific types (i.e. allows all unspecified types) and does not allow unbounded extension. This is the set of sets that are not members of themselves. This inability to be both consistent and completely enumerated over all possible extension, is Gödel's incompleteness theorems. Liskov Substition Principle: generally it is an undecidable problem whether any set is the subset of another, i.e. inheritance is generally undecidable. Linsky Referencing: it is undecidable what the computation of something is, when it is described or perceived, i.e. perception (reality) has no absolute point of reference. Coase's theorem: there is no external reference point, thus any barrier to unbounded external possibilities will fail. Second law of thermodynamics: the entire universe (a closed system, i.e. everything) trends to maximum disorder, i.e. maximum independent possibilities.

利斯科夫替换原则(来自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)。

你可以在那里找到一个解释，什么是利斯科夫替换原则，一般线索帮助你猜测你是否已经违反了它，一个方法的例子，将帮助你使你的类层次结构更安全。