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

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

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

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

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

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

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

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

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

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

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

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可能会在某些时候导致代码错误。

该原则由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。事实上，派生类正方形的创建会导致基类矩形的变化。

以下是这篇文章的摘录，很好地澄清了事情:

(. .为了理解一些原则，重要的是要意识到它什么时候被违反了。这就是我现在要做的。

违反这一原则意味着什么?它意味着对象不履行用接口表示的抽象所施加的契约。换句话说，这意味着您错误地识别了抽象。

考虑下面的例子:

interface Account
{
    /**
     * Withdraw $money amount from this account.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}
class DefaultAccount implements Account
{
    private $balance;
    public function withdraw(Money $money)
    {
        if (!$this->enoughMoney($money)) {
            return;
        }
        $this->balance->subtract($money);
    }
}

是否违反LSP?是的。这是因为帐户合同告诉我们帐户将被提取，但情况并非总是如此。那么，我该怎么做才能解决这个问题呢?我只是修改了合同:

interface Account
{
    /**
     * Withdraw $money amount from this account if its balance is enough.
     * Otherwise do nothing.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}

Voilà，现在合同已得到满足。

这种微妙的违反通常会使客户有能力区分所使用的具体对象之间的差异。例如，给定第一个Account的契约，它看起来像下面这样:

class Client
{
    public function go(Account $account, Money $money)
    {
        if ($account instanceof DefaultAccount && !$account->hasEnoughMoney($money)) {
            return;
        }
        $account->withdraw($money);
    }
}

而且，这自动违反了开闭原则(即取款要求)。因为你永远不知道如果违反合同的对象没有足够的钱会发生什么。它可能什么都不返回，可能会抛出异常。所以你必须检查它是否hasEnoughMoney()——这不是接口的一部分。因此这种强制的依赖于具体类的检查违反了OCP。

这一点也解决了我经常遇到的关于LSP违反的误解。它说:“如果父母的行为在孩子身上改变了，那么它就违反了LSP。”然而，事实并非如此——只要孩子不违反父母的契约。

我在每个答案中都看到了矩形和正方形，以及如何违反LSP。

我想用一个真实的例子来展示LSP是如何符合的:

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return $result; 
    }
}

这种设计符合LSP，因为无论我们选择使用哪种实现，行为都不会改变。

是的，你可以在这个配置中违反LSP，做一个简单的改变，像这样:

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return ['result' => $result]; // This violates LSP !
    }
}

现在子类型不能以同样的方式使用，因为它们不再产生相同的结果。