让我试着考虑一个接口:

interface Planet{
}

这是由类实现的:

class Earth implements Planet {
    public $radius;
    public function construct($radius) {
        $this->radius = $radius;
    }
}

你将使用地球作为:

$planet = new Earth(6371);
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

现在再考虑一个扩展到地球的阶级:

class LiveablePlanet extends Earth{
   public function color(){
   }
}

根据LSP的说法，你应该可以用LiveablePlanet代替Earth，而且它不会破坏你的系统。如:

$planet = new LiveablePlanet(6371);  // Earlier we were using Earth here
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

这里的例子

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在技术上是什么:你基本上希望能够从子类型细节中抽象出来，并安全地使用超类型。

所以利斯科夫有3条基本规则:

Signature Rule : There should be a valid implementation of every operation of the supertype in the subtype syntactically. Something a compiler will be able to check for you. There is a little rule about throwing fewer exceptions and being at least as accessible as the supertype methods. Methods Rule: The implementation of those operations is semantically sound. Weaker Preconditions : The subtype functions should take at least what the supertype took as input, if not more. Stronger Postconditions: They should produce a subset of the output the supertype methods produced. Properties Rule : This goes beyond individual function calls. Invariants : Things that are always true must remain true. Eg. a Set's size is never negative. Evolutionary Properties : Usually something to do with immutability or the kind of states the object can be in. Or maybe the object only grows and never shrinks so the subtype methods shouldn't make it.

所有这些属性都需要保留，并且额外的子类型功能不应该违反超类型属性。

如果这三件事都处理好了，那么您就从底层的东西中抽象出来了，并且您正在编写松散耦合的代码。

来源:程序开发在Java -芭芭拉利斯科夫

大局:

利斯科夫替换原理是什么?它是关于什么是(什么不是)给定类型的子类型。 为什么它如此重要?因为子类型和子类之间是有区别的。

例子

与其他答案不同的是，我不会从违反Liskov替换原则(LSP)开始，而是从符合LSP开始。我使用Java，但在每种OOP语言中几乎都是一样的。

圆和彩色圆

几何例子在这里似乎很流行。

class Circle {
    private int radius;

    public Circle(int radius) {
        if (radius < 0) {
            throw new RuntimeException("Radius should be >= 0");
        }
        this.radius = radius;
    }

    public int getRadius() {
        return this.radius;
    }
}

半径不允许为负。这是一个子类:

class ColoredCircle extends Circle {
    private Color color; // defined elsewhere

    public ColoredCircle(int radius, Color color) {
        super(radius);
        this.color = color;
    }

    public Color getColor() {
        return this.color;
    }
}

从LSP来看，这个子类是Circle的子类型。

LSP的状态为:

如果对于类型S的每个对象o1，都有一个类型T的对象o2，使得对于所有用T定义的程序P，当o1取代o2时，P的行为不变，那么S是T的子类型(Barbara Liskov，“数据抽象和层次结构”，SIGPLAN通知，23,5(1988年5月))。

这里，对于每个ColoredCircle实例o1，考虑Circle实例具有相同的半径o2。对于每个使用Circle对象的程序，如果您将o2替换为o1，则任何使用Circle的程序的行为在替换之后都将保持不变。(注意，这只是理论上的:使用ColoredCircle实例会比使用Circle实例更快地耗尽内存，但这与本文无关。)

我们如何根据o1求出o2 ?我们只是去掉color属性，保留radius属性。我称这个变换为o1 - >o2是CircleColor空间在Circle空间上的投影。

反例

让我们再创建一个例子来说明LSP的违反。

圆形和方形

想象一下前面Circle类的子类:

class Square extends Circle {
    private int sideSize;

    public Square(int sideSize) {
        super(0);
        this.sideSize = sideSize;
    }

    @Override
    public int getRadius() {
        return -1; // I'm a square, I don't care
    }

    public int getSideSize() {
        return this.sideSize;
    }
}

LSP违反

现在，看看这个程序:

public class Liskov {
    public static void program(Circle c) {
        System.out.println("The radius is "+c.getRadius());
    }

我们用一个Circle对象和一个Square对象测试程序。

    public static void main(String [] args){
        Liskov.program(new Circle(2)); // prints "The radius is 2"
        Liskov.program(new Square(2)); // prints "The radius is -1"
    }
}

发生了什么事?直观地说，虽然Square是Circle的一个子类，但Square不是Circle的子类型，因为没有一个常规的Circle实例的半径是-1。

形式上，这违反了利斯科夫替换原则。

我们有一个用Circle定义的程序，在这个程序中没有Circle对象可以替换新的Square(2)(顺便说一下，也没有任何Square实例)，并且保持行为不变:记住，任何Circle的半径总是正的。

子类和子类型

现在我们知道为什么子类并不总是子类型。当子类不是子类型时，即存在LSP违反时，某些程序(至少有一个)的行为并不总是预期的行为。这是非常令人沮丧的，通常被解释为一个错误。

在理想的情况下，编译器或解释器将能够检查给定的子类是否是真正的子类型，但我们并不是在理想的情况下。

静态类型

如果存在一些静态类型，则在编译时被父类签名绑定。Square.getRadius()不能返回String或List。

如果没有静态类型，如果一个参数的类型是错误的(除非类型是弱的)或参数的数量不一致(除非语言是非常允许的)，您将在运行时得到一个错误。

关于静态类型的注意:有返回类型的协方差(S的方法可以返回T的相同方法的返回类型的子类)和参数类型的逆变性(S的方法可以接受T的相同方法的相同参数的超类)的机制，这是下面解释的先决条件和后置条件的具体情况。

合同设计

有更多的。有些语言(我想到了Eiffel)提供了一种机制来强制执行LSP。

先不说确定初始对象o1的投影o2，如果用o1代替o2 if，对于任何参数x和任何方法f，我们可以期望任何程序都有相同的行为:

如果o2.f(x)是一个有效调用，那么o1.f(x)也应该是一个有效调用(1)。 o1.f(x)的结果(返回值，在控制台上显示等)应该等于o2.f(x)的结果，或者至少同样有效(2)。 o1.f(x)应该让o1处于内部状态，o2.f(x)应该让o2处于内部状态，这样下一次函数调用将确保(1)，(2)和(3)仍然有效(3)。

(注意，如果函数f是纯函数，则(3)是免费给出的。这就是为什么我们喜欢使用不可变对象。)

这些条件是关于类的语义(期望什么)，而不仅仅是类的语法。而且，这些条件非常强。但是它们可以用契约式编程设计中的断言来近似。这些断言是确保支持类型语义的一种方法。破坏契约会导致运行时错误。

前提条件定义了什么是有效的调用。当子类化一个类时，前提条件只能被削弱(S.f接受的比T.f多)(a)。 后置条件定义了什么是有效结果。当子类化一个类时，后置条件只能被加强(S.f比T.f提供更多)(b)。 不变量定义了什么是有效的内部状态。当子类化一个类时，不变量必须保持不变(c)。

我们可以大致看到，(a)保证了(1)，(b)保证了(2)，但是(c)比(3)弱。此外，断言有时难以表达。

假设一个类Counter有一个唯一的方法Counter. Counter()，该方法返回下一个整数。怎么写后置条件呢?假设一个类Random有一个方法Random.高斯()，该方法返回一个介于0.0和1.0之间的浮点数。如何编写后置条件来检查分布是否为高斯分布?这也许是可能的，但成本太高，我们将依赖于测试而不是后置条件。

结论

不幸的是，子类并不总是子类型。这可能会导致意想不到的行为——bug。

面向对象语言提供了避免这种情况的机制。首先在语法层面。在语义层面上也是如此，这取决于编程语言:可以使用断言在程序文本中编码一部分语义。但是，由您来确保子类是子类型。

还记得你什么时候开始学习OOP吗?“如果关系是is - a，那么使用继承”。另一种方式也是如此:如果使用继承，请确保关系是is - a。

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.

使用LSP的一个重要例子是在软件测试中。

如果我有一个类a，它是B的一个符合lsp的子类，那么我可以重用B的测试套件来测试a。

为了完全测试子类A，我可能需要添加更多的测试用例，但至少我可以重用所有超类B的测试用例。

实现这一点的一种方法是构建McGregor所说的“用于测试的并行层次结构”:我的ATest类将继承BTest。然后需要某种形式的注入来确保测试用例使用类型A的对象而不是类型B的对象(一个简单的模板方法模式就可以了)。

注意，对所有子类实现重用超级测试套件实际上是一种测试这些子类实现是否与lsp兼容的方法。因此，人们也可以主张应该在任何子类的上下文中运行超类测试套件。

另请参阅对Stackoverflow问题的回答“我是否可以实现一系列可重用测试来测试接口的实现?”