里氏替换原则（LiskovSubstitution Principle， LSP）
@H_502_9@ 看到里氏替换原则，感觉很好奇，名字很怪，哈哈哈，其实这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的，向伟大的IT届的女精英们致敬！
@H_502_9@定义1：如果对应类型为S的对象o1，有类型为T的对象o2，使得以T定义的所有程序P，在所有的对象o1都替换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
@H_502_9@定义2：所有引用基类的地方都必须能够透明地使用其子类的对象。
@H_502_9@问题由来：有一功能P1，由类A完成。现需要对功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
@H_502_9@
@H_502_9@解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的非抽象方法，也尽量不要重载父类A的方法。
@H_502_9@ 继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
@H_502_9@ 继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，子类在继承父类的同时，会对父类中的非抽象方法进行重写或重载，那么在一定程度上污染了父类；此外，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
@H_502_9@ 举例说明继承的风险，我们需要完成一个两数相减的功能，由类A来负责。特别说明：以下的例子来自于网友卡奴达摩的专栏，在此特别感谢！
@H_502_9@运行结果：
@H_502_9@100-50=50
100-80=20
@H_502_9@ 后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：
