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{}

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

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

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

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

让我们用Java来说明:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }

   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

class Car extends TransportationDevice
{
   @Override
   void startEngine() { ... }
}

这里没有问题，对吧?汽车绝对是一种交通工具，在这里我们可以看到它重写了其超类的startEngine()方法。

让我们添加另一个交通工具:

class Bicycle extends TransportationDevice
{
   @Override
   void startEngine() /*problem!*/
}

现在一切都不按计划进行了!是的，自行车是一种交通工具，但是，它没有发动机，因此，startEngine()方法不能实现。

这些都是违反利斯科夫代换法的问题 原则导致，他们通常可以被一个公认的 方法，该方法什么也不做，甚至不能实现。

这些问题的解决方案是一个正确的继承层次结构，在我们的例子中，我们将通过区分带引擎和不带引擎的运输设备类别来解决问题。尽管自行车是一种交通工具，但它没有发动机。在这个例子中，我们对交通工具的定义是错误的。它不应该有引擎。

我们可以像下面这样重构TransportationDevice类:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }
}

现在我们可以为非机动设备扩展TransportationDevice。

class DevicesWithoutEngines extends TransportationDevice
{  
   void startMoving() { ... }
}

并为机动设备扩展TransportationDevice。这里更适合添加Engine对象。

class DevicesWithEngines extends TransportationDevice
{  
   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

因此，我们的Car类变得更加专门化，同时坚持利斯科夫替换原则。

class Car extends DevicesWithEngines
{
   @Override
   void startEngine() { ... }
}

我们的Bicycle类也遵循利斯科夫替换原理。

class Bicycle extends DevicesWithoutEngines
{
   @Override
   void startMoving() { ... }
}

Liskov's Substitution Principle(LSP) All the time we design a program module and we create some class hierarchies. Then we extend some classes creating some derived classes. We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise, the new classes can produce undesired effects when they are used in existing program modules. Liskov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

例子:

Below is the classic example for which the Liskov's Substitution Principle is violated. In the example, 2 classes are used: Rectangle and Square. Let's assume that the Rectangle object is used somewhere in the application. We extend the application and add the Square class. The square class is returned by a factory pattern, based on some conditions and we don't know the exact what type of object will be returned. But we know it's a Rectangle. We get the rectangle object, set the width to 5 and height to 10 and get the area. For a rectangle with width 5 and height 10, the area should be 50. Instead, the result will be 100

    // Violation of Likov's Substitution Principle
class Rectangle {
    protected int m_width;
    protected int m_height;

    public void setWidth(int width) {
        m_width = width;
    }

    public void setHeight(int height) {
        m_height = height;
    }

    public int getWidth() {
        return m_width;
    }

    public int getHeight() {
        return m_height;
    }

    public int getArea() {
        return m_width * m_height;
    }
}

class Square extends Rectangle {
    public void setWidth(int width) {
        m_width = width;
        m_height = width;
    }

    public void setHeight(int height) {
        m_width = height;
        m_height = height;
    }

}

class LspTest {
    private static Rectangle getNewRectangle() {
        // it can be an object returned by some factory ...
        return new Square();
    }

    public static void main(String args[]) {
        Rectangle r = LspTest.getNewRectangle();

        r.setWidth(5);
        r.setHeight(10);
        // user knows that r it's a rectangle.
        // It assumes that he's able to set the width and height as for the base
        // class

        System.out.println(r.getArea());
        // now he's surprised to see that the area is 100 instead of 50.
    }
}

结论: 这个原则只是开闭原则的延伸 意味着我们必须确保新的派生类正在扩展 基类而不改变它们的行为。

参见:开闭原则

对于更好的结构，还有一些类似的概念:约定优于配置

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是相同的。