概要
Functions that use pointers or references to base classesmust be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。
即：
◇ 所以使用基类代码的地方，用派生类代码替换后，能够正确的执行动作处理。
◇ 换句话说，如果派生类替换了基类后，不能够正确执行动作，那么他们的继承关系就应该废除。
换个说法，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：
◇ 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。
- if(objtypeofClass1){
- dosomething
- }elseif(objtypeofClass2){
- dosomethingelse
- }
◇ 子类应当可以替换父类并出现在父类能够出现的任何地方，
或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。
里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：
◇ 类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，
则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。
◇ 动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。
类的继承原则：
Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里，举了Rectangle和Square的例子。
这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要
部分来说明 里氏替换原则 对类的继承上的约束。
这里Rectangle是基类，Square从Rectangle继承。
这种继承关系有什么问题吗？
假如已有的系统中存在以下既有的业务逻辑代码：
则对应于扩展类Square，在调用既有业务逻辑时：
时会抛出一个RuntimeException异常。这显然违反了LSP原则。
动作正确性保证：
因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时，
根据LSP的定义，不会给已有的系统引入新的错误。
Design by Contract
根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述，
对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，
只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，
如果一个方法的执行会导致这个方法的后续条件不成立，那么 这个方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：
１）前提条件不强于基类．
２）后续条件不弱于基类．
换 句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。
亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。
同样，继承类必须顺从基类的所有后续条件，亦即，
继承类方法的行为和输出不得违反由基类建立起来的任 何约束，不能让用户对继承类方法的输出感到困惑。
这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。
在很多情况下，在设计初期我们类之间的关系不是很明确，
LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。
总结
LSP: 子类必须能够替换基类。
Subtypes must besubstitutable for their base types.
1. LSP关注的是怎样良好的使用继承.
2. 必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。
3. LSP清晰的指出，OOD的IS-A关系是就行为方式而言，
行为方式是可以进行合理假设的，是客户程序所依赖的。
4. LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。
模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。
而假设是难以预测的，直到设计臭味出现的时候才处理它们。
5. 对于LSP的违反也潜在的违反了OCP
原文链接：https://www.f2er.com/javaschema/287088.html