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

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

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

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

假设我们在代码中使用了一个矩形

r = new Rectangle();
// ...
r.setDimensions(1,2);
r.fill(colors.red());
canvas.draw(r);

在几何课上，我们学过正方形是一种特殊类型的矩形，因为它的长宽相等。让我们根据下面的信息创建一个Square类:

class Square extends Rectangle {
    setDimensions(width, height){
        assert(width == height);
        super.setDimensions(width, height);
    }
} 

如果我们在第一个代码中将矩形替换为正方形，那么它将会中断:

r = new Square();
// ...
r.setDimensions(1,2); // assertion width == height failed
r.fill(colors.red());
canvas.draw(r);

这是因为正方形有一个我们在矩形类中没有的新前提条件:width == height。根据LSP，矩形实例应该被矩形子类实例替代。这是因为这些实例通过了矩形实例的类型检查，因此它们将在代码中导致意外错误。

这是wiki文章中“在子类型中不能加强先决条件”部分的一个例子。因此，总而言之，违反LSP可能会在某些时候导致代码错误。

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

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

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. [...]

LSP的这种形式太强大了:

如果对于每个类型为S的对象o1，都有一个类型为T的对象o2，使得对于所有用T定义的程序P，当o1取代o2时，P的行为不变，那么S是T的子类型。

这基本上意味着S是t的另一个完全封装的实现，我可以大胆地认为性能是P行为的一部分……

因此，基本上，任何延迟绑定的使用都违反了LSP。当我们用一种类型的对象替换另一种类型的对象时，获得不同的行为是OO的全部意义所在!

维基百科引用的公式更好，因为属性取决于上下文，并不一定包括程序的整个行为。

到目前为止，我发现LSP最清晰的解释是“利斯科夫替换原则说，派生类的对象应该能够替换基类的对象，而不会给系统带来任何错误，也不会修改基类的行为”。文中给出了违反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.