开闭原则（OCP : The Open-Close Principle)

描述：软件实体（类、模型、函数等等）应该是可以扩展的，但是不可修改。

遵循开闭原则设计出的模块具有两个主要的特征。它们是：
1. “对于扩展是开放的”（Open for extension）。
   这意味着模块的行为是可以扩展的。当应用的需要改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。换句话说，我们可以改变模块的功能。
2. “对于更改是封闭的”（Closed for modification）。
   对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者Java的.jar文件，都无需改动。

对于OCP，关键的是 抽象
模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体，所以它对于更改可以是关闭的。同时，通过从这个抽象体派生，也可以扩展此模块的行为。

在许多方面，OCP都是面向对象设计的核心所在。但实际应用中，滥用OCP原则也是错误的。正确的做法是应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

Liskov替换原则（LSP）

描述：子类型（subtype）必须能够替换掉它们的基类型（base type）。

此原则是Barbara Liskov首次在1988年写下的。所以就叫做Liskov替换原则。她如此写到：
“这里需要如下替换性质：若对每个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P行为功能不变，则S是T的子类型。

LSP然我们得出一个非常重要的结论：一个模型，如果孤立的看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现。

在考虑一个特定设计是否恰当时，不能完全孤立的来看这个解决方案。必须要根据该设计的使用者所做出的合理假设来审视它。

有 谁知道设计的使用者会做出什么样的合理假设呢？大多数这样的假设都很难预测。事实上，如果试图去预测所有这些假设，我们所得到的系统很可能会充满不必要的 复杂性的臭味。因此，像所有其它原则一样了，通常最好的办法就是只预测那些最明显的对于LSP的违反情况，而推迟所有其它的预测，直到出现相关的脆弱性的 臭味时，才去处理它们。

IS-A是关于行为的。
LSP清晰的指出，OOD中IS－A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序所依赖的。

基于契约设计
基 于契约设计（DBC：Design By Contract）。使用DBC，类的编写者能够显式的规定针对该类的契约。客户代码的编写者可以通过该契约获悉可以依赖的行为方式。契约是通过为每个方 法声明的前置条件（preconditions)和后置条件（postconditions)来指定的。要使一个方法得以执行，前置条件必须要为真。执行 完毕后，该方法要保证后置条件为真。

在单元测试中指定契约
也可以通过编写单元测试的方式来指定契约。客户代码编写者会去查看这些单元测试，这样他们就可以知道对于要使用的类，应该做什么合理的假设。

启发式规则和习惯用法

1.派生类中的退化函数
  在基类中实现了f()方法，在派生类中的函数f()就是退化的，派生类中的退化函数并不总表示为违反LSP，但是当存在这种情况时，还是值得注意一下的。
2.从派生类中抛出异常
  在派生类的方法中添加了其基类不会抛出的异常。如果基类的使用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替换性。此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。

总 结：OCP是OOD中很多原则的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性、可重用性以及健壮性。LSP是使OCP成为可能的主要原 则之一。正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的。因此，如果没有显式的 强制基类类型的契约，那么代码就必须良好的并且明显的表达出这一点。
      术语IS-A的含义过于广泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性”，这里的可替换性可以通过显式或者隐式的契约来定义。