定义：
程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换，也就是说所有引用基类的地方必须能透明地使用其子类的对象。通俗的来说，子类可以扩展父类的功能，但不能改变父类原有的功能。
由来：
第一次看见这个里氏替换原则的名字会觉着很奇特，根据以往的经验这一看就是外国友人首先提出的概念，然后便以她的姓命名该原则。确实是这样，它由芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。里氏替换原则英文名称为Liskov Substitution principle，所以简称为LSP。
深入：
里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含了四层含义：
- 子类必须完全实现父类的方法
我们在做系统设计时经常编写接口和抽象类，然后编码继承它们，其实这里已经应用了里氏替换原则。比如，我们简单实现一下CS中的各种枪（定义抽象类，然后继承），枪的类图如下所示：
枪的主要职责是杀人，每种枪都有自己的特点。shou枪是单发且射程较近，步枪射程远威力大，机枪主要用于扫射。同时定义一个士兵类，KillEnemy(AbstractGun gun)方法使用枪来杀人，具体使用什么枪调用时才会知道。
枪抽象类、常用枪和士兵类代码实现如下所示：
/// <summary>
/// 枪抽象类
/// </summary>
public abstract class AbstractGun
{
public abstract void Shoot();
}
/// <summary>
/// shou枪
/// </summary>
public class HandGun : AbstractGun
{
public override void Shoot()
{
Console.WriteLine("shou枪射击...");
}
}
/// <summary>
/// 步枪
/// </summary>
public class Rifle : AbstractGun
{
public override void Shoot()
{
Console.WriteLine("步枪射击...");
}
}
/// <summary>
/// 机枪
/// </summary>
public class MachineGun : AbstractGun
{
public override void Shoot()
{
Console.WriteLine("机枪射击...");
}
}
/// <summary>
/// 士兵类
/// </summary>
public class Solder
{
public void KillEnemy(AbstractGun gun)
{
Console.WriteLine("士兵开始杀人...");
gun.Shoot();
}
}
场景类(主函数)代码如下所示：
class Client
{
static void Main(string[] args)
{
var solder = new Solder();
solder.KillEnemy(new Rifle());
Console.ReadKey();
}
}
运行结果如下所示：
在这个程序中，我们给三毛这个士兵一把步枪，然后就开始杀敌了，如果三毛要使用机枪当然也可以,直接把solder.killEnemy(new Rifle())修改为 solder.killEnemy(new MachineGun())就可以了，在编写程序时Solider士兵类根本就不用知道是哪个型号的枪（子类）被传入。
注意在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
如果现在我们想嫁个玩具枪，那我们就加一个TonyGun类继承AbstractGun，加入玩具枪后新的类图如下所示：
但是考虑到实际情况，因为玩具枪一般是杀不死人的，所以玩具枪里的类是不能实现杀人的，如下代码所示只能把该方法置空：
/// <summary>
/// 玩具枪
/// </summary>
public class TonyGun : AbstractGun
{
public override void Shoot()
{
//玩具枪不能射击，这里就不能实现了
}
}
把枪改为玩具枪，演示代码如下所示：
class Client
{
static void Main(string[] args)
{
var solder = new Solder();
solder.KillEnemy(new TonyGun());
Console.ReadKey();
}
}
运行结果如下：
结果只提示士兵杀人却没有发射子弹（因为用的是玩具枪，有点搞）。
在这种情况下，我们发现业务调用类已经出现了问题，正常的业务逻辑已经不能运行，那怎么办？好办，有两种解决办法：
1.在Soldier类中增加instanceof的判断，如果是玩具枪，就不用来杀敌人。这个方法可以解决问题，但是你要知道，在程序中，每增加一个类，所有与这个父类有关系的类都必须修改，你觉得可行吗？如果你的产品出现了这个问题，因为修正了这样一个Bug，就要求所有与这个父类有关系的类都增加一个判断，客户非跳起来跟你干架不可！你还想要你的客户忠诚你吗？显然，这个方案被否定了。
2.ToyGun脱离继承，建立一个独立的父类，为了做到代码可以复用，可以与AbastractGun建立关联委托关系
注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。
- 子类可以有自己的个性
子类当然可以有自己的行为和外观（也就是方法和属性），这里为什么要提呢？因为里氏替换原则是不能到这使用的的，子类可以替换父类，但是父类不能替换父类（如果能替换也就没必要派生子类了），具体就不解释了（定义就是这么定义的，道理比较浅显），用下面的图做一下简单的说明：
- 覆盖或实现父类的方法时输入参数可以被放大
方法中的输入参数称为前置条件，这是什么意思呢？大家做过Web Service开发就应该知道有一个“契约优先”的原则，也就是先定义出WSDL接口，制定好双方的开发协议，然后再各自实现。里氏替换原则也要求制定一个契约，就是父类或接口，这种设计方法也叫做Design by Contract，契约设计，是与里氏替换原则融合在一起的。契约制定了，也就同时制定了前置条件和后置条件，前置条件就是你要让我执行，就必须满足我的条件；后置条件就是我执行完了需要反馈，标准是什么。
子类在没有覆写父类的方法的前提下，子类方法被执行了，这会引起业务逻辑混乱，因为在实际应用中父类一般都是抽象类，子类是实现类，你传递一个这样的实现类就会“歪曲”了父类的意图，引起一堆意想不到的业务逻辑混乱，所以子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。
- 覆盖或实现父类的方法时输出结果可以被缩小
这是什么意思呢，父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说要么S和T是同一个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法，天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在里氏替换原则要求下，就是子类的输入参数大于或等于父类的输入参数，也就是说你写的这个方法是不会被调用到的，参考上面讲的前置条件。
采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！
总结：
看上去很不可思议，因为我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑的好好的。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？
后果就是：你写的代码出问题的几率将会大大增加。
PS：最后提交时竟然提示[手.枪]是违禁词，只好改成了shou枪