目录
[10.1 Liskov替换原则（LSP）](#10.1 Liskov替换原则（LSP）)
[10.2 一个违反LSP的简单例子](#10.2 一个违反LSP的简单例子)
[10.6 启发式规则和习惯用法](#10.6 启发式规则和习惯用法)
[10.7 结论](#10.7 结论)
1：PDF上传链接
OCP背后的主要机制是抽象(abstraction)和多态(polymorphism)。在静态类型语言中，比如C++和Java,支持抽象和多态的关键机制之一是继承(inheritance)。正是使用了继承，我们才可以创建实现其基类(base class)中抽象方法的派生类。
是什么设计规则在支配着这种特殊的继承用法呢？最佳的继承层次的特征又是什么呢？怎样的情况会使我们创建的类层次结构掉进不符合OCP的陷阱中去呢？这些正是Liskov替换原则(LSP)要解答的问题。
10.1 Liskov替换原则（LSP）
对于LSP可以做如下解释：
子类型(subtype)必须能够替换掉它们的基类型(base type).
Barbara Liskov首次写下这个原则是在1988年。她说道，
这里需要如下替换性质：若对每个类型S的对象01，都存在一个类型T的对象02，使得在所有针对T编写的程序P中，用01替换02后，程序P行为功能不变，则S是T的子类型.
想想违反该原则的后果，LSP的重要性就不言而喻了。假设有一个函数f,它的参数为指向某个基类B的指针(pointer)或者引用(reference.)。同样假设有B的某个派生类D,如果把D的对象作为B类型传递给f,会导致f出现错误的行为。那么D就违反了LSP。显然，D对于f来说是脆弱的。
f的编写者会想去对D进行一些测试，以便于在把D的对象传递给f时，可以使f具有正确的行为。这个测试违反了OCP,因为此时f对于B的所有不同的派生类都不再是封闭的。这样的测试是一种代码的臭味，它是缺乏经验的开发人员（或者，更糟的，匆忙的开发人员）在违反了LSP时所产生的结果。
10.2 一个违反LSP的简单例子
对于LSP的违反常常会导致以明显违反OCP的方式使用运行时类型辨别(RTTI)。这种方式常常是使用-"个显式的仟语句或者fse链去确定一个对象的类型，以便于可以选择针对该类型的正确行为。考虑...下程序10.1。
图10.1.1
很显然，程序lO.1中的DrawShape函数违反了OCP。它必须知道Shape类所有的派生类，并且每次创建-一个从Sape类派生的新类时都必须要更改它，甚至很多人肯定地认为这种函数结构简直是对良好设计的诅咒。那么，是什么促使程序员编写出像这样的一个函数呢？
假设Jo是一个工程师。他学习过面向对象技术，并且认为多态的开销大得难以忍受。因此，他定义了一个没有任何虚函数的Shape类。类（结构）Square和Circle从Shape类派生，并具有Draw)函数，但是它们没有覆写(override)Shape类中的函数。因为Circle类和Square类不能替换Shape类，所以DrawShape函数必须要仔细检查输入的Shape对象，确定它的类型，接着调用正确的Draw函数。
Square类和Circle类不能替换Shape类其实是违反了LSP,这个违反又迫使DrawShape函数违反了OCP,因而，对于LSP的违反也潜在地违反了OCP。
10.6 启发式规则和习惯用法
有一些简单的启发规则可以提供一些有关违反LSP的提示。这些规则都和以某种方式从其基类中去除功能的派生类有关。完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违反了LSP。
10.7 结论
OCP是OOD中很多说法的核心。如果这个原则应用得有效，应用程序就会具有更多的可维护性、可重用性以及健壮性。LSP是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。因此，如果没有显式地强制基类类型的契约，那么代码就必须良好地并且明显地表达出这一点。
术语"IS-A"的含意过于宽泛以至于不能作为子类型的定义。子类型的正确定义是"可替换性的"，这里的可替换性可以通过显式或者隐式的契约来定义。