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

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

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

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

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

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

这里有一个清单来确定你是否违反了利斯科夫法则。

如果你违反了以下项目之一->，你违反了里斯科夫。 如果你不违反任何->不能得出任何结论。

检查表:

No new exceptions should be thrown in derived class: If your base class threw ArgumentNullException then your sub classes were only allowed to throw exceptions of type ArgumentNullException or any exceptions derived from ArgumentNullException. Throwing IndexOutOfRangeException is a violation of Liskov. Pre-conditions cannot be strengthened: Assume your base class works with a member int. Now your sub-type requires that int to be positive. This is strengthened pre-conditions, and now any code that worked perfectly fine before with negative ints is broken. Post-conditions cannot be weakened: Assume your base class required all connections to the database should be closed before the method returned. In your sub-class you overrode that method and left the connection open for further reuse. You have weakened the post-conditions of that method. Invariants must be preserved: The most difficult and painful constraint to fulfill. Invariants are sometimes hidden in the base class and the only way to reveal them is to read the code of the base class. Basically you have to be sure when you override a method anything unchangeable must remain unchanged after your overridden method is executed. The best thing I can think of is to enforce these invariant constraints in the base class but that would not be easy. History Constraint: When overriding a method you are not allowed to modify an unmodifiable property in the base class. Take a look at these code and you can see Name is defined to be unmodifiable (private set) but SubType introduces new method that allows modifying it (through reflection): public class SuperType { public string Name { get; private set; } public SuperType(string name, int age) { Name = name; Age = age; } } public class SubType : SuperType { public void ChangeName(string newName) { var propertyType = base.GetType().GetProperty("Name").SetValue(this, newName); } }

还有2项:方法参数的逆变性和返回类型的协方差。但这在c#中是不可能的(我是c#开发人员)，所以我不关心它们。

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

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

它指出，如果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{}

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

简单来说，LSP是指同一超类的对象应该能够在不破坏任何东西的情况下相互交换。

例如，如果我们有一个从Animal类派生的Cat和Dog类，那么任何使用Animal类的函数都应该能够使用Cat或Dog，并且行为正常。