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

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

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

考虑下面的例子:

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。”然而，事实并非如此——只要孩子不违反父母的契约。

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

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

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

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

以Board数组的形式实现ThreeDBoard会有用吗?

也许你想把不同平面上的ThreeDBoard切片作为一个板。在这种情况下，您可能希望为Board抽象出一个接口(或抽象类)，以允许多种实现。

就外部接口而言，您可能希望为TwoDBoard和ThreeDBoard提取一个Board接口(尽管上述方法都不适合)。

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

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

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

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

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

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

LSP的这种形式太强大了:

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

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

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

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

我想每个人都了解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 -芭芭拉利斯科夫