到目前为止，我发现LSP最清晰的解释是“利斯科夫替换原则说，派生类的对象应该能够替换基类的对象，而不会给系统带来任何错误，也不会修改基类的行为”。文中给出了违反LSP的代码示例并进行了修复。

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

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

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

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

A square is a rectangle where the width equals the height. If the square sets two different sizes for the width and height it violates the square invariant. This is worked around by introducing side effects. But if the rectangle had a setSize(height, width) with precondition 0 < height and 0 < width. The derived subtype method requires height == width; a stronger precondition (and that violates lsp). This shows that though square is a rectangle it is not a valid subtype because the precondition is strengthened. The work around (in general a bad thing) cause a side effect and this weakens the post condition (which violates lsp). setWidth on the base has post condition 0 < width. The derived weakens it with height == width.

因此，可调整大小的正方形不是可调整大小的矩形。

Liskov替换原理(LSP, LSP)是面向对象编程中的一个概念，它指出:

函数使用指针或 基类的引用必须是 能够使用派生类的对象 在不知不觉中。

LSP的核心是关于接口和契约，以及如何决定何时扩展一个类，还是使用另一种策略(如组合)来实现您的目标。

我所见过的说明这一点的最有效的方法是《Head First OOA&D》。它们呈现的场景是，你是一名致力于为策略游戏构建框架的项目开发者。

他们展示了一个类，它代表一个板子，看起来像这样:

所有的方法都以X和Y坐标作为参数来定位tile在二维tile数组中的位置。这将允许游戏开发者在游戏过程中管理棋盘上的单位。

这本书继续改变了要求，说游戏框架工作也必须支持3D游戏板，以适应有飞行的游戏。因此引入了一个ThreeDBoard类，它扩展了Board。

乍一看，这似乎是个不错的决定。Board提供了高度和宽度属性，ThreeDBoard提供了Z轴。

当你看到从董事会继承的所有其他成员时，它就失效了。AddUnit, GetTile, GetUnits等方法在Board类中都采用X和Y参数，但ThreeDBoard也需要Z参数。

因此，您必须使用Z参数再次实现这些方法。Z参数没有Board类的上下文，从Board类继承的方法失去了意义。试图使用ThreeDBoard类作为其基类Board的代码单元将非常不走运。

也许我们应该另想办法。ThreeDBoard应该由Board对象组成，而不是扩展Board。Z轴上每单位一个板子对象。

这允许我们使用良好的面向对象原则，如封装和重用，并且不违反LSP。

让我们用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() { ... }
}

LSP说“对象应该被它们的子类型替换”。 另一方面，这一原则指向

子类永远不应该破坏父类的类型定义。

通过以下示例，可以更好地理解LSP。

没有太阳能发电:

public interface CustomerLayout{

    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            return; //it isn`t rendered in this case
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}

LSP修复:

public interface CustomerLayout{
    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            showAd();//it has a specific behavior based on its requirement
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}