单一职责原则（SRP : Single Response Principle)
就一个类而言，应该仅有一个引起它变化的原因。
在这里，职责的定义是： “变化的原因”。
对于何时遵循SRP有以下的考虑：
1.如果应用程序的变化会影响到类中某一种职责，那么就应该将它与另一种职责分开，这样做可以避免客户应用程序和类中的这两职责耦合在一起。
2.如果应用程序的变化总是会导致两个职责同时变化，那么就不必要分离它们。实际上，分离它们会引起不必要的复杂性。
从上可以得知：变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆，那么去应用SRP，或者任何其它原则都是不明智。
实际应用：持久化（Persistence）
实际开发中，考虑到业务规则是会频繁改变的，而持久化的方式却不会如此频繁的变化，并且变化的原因也是完全不同的。如果把业务规则和持久化方式绑定到一起，就会为以后的开发、维护造成麻烦。运用分层（layer）架构模式或者TDD开发方式可以很早分离这两个职责，特殊情况下，还可以使用FACADE或者PROXY模式对设计进行重构，分离这两个职责。
开闭原则（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的含义过于广泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性”，这里的可替换性可以通过显式或者隐式的契约来定义。
