在21世纪的前几年里，“Uncle Bob”Robert Martin引入了用OOP开发软件的五条原
则，其目的是设计出更易于维护的高质量系统。无论是设计新应用程序，还是重构现有基
本代码，这些SOLID原则都成为开发人员的地图。
1. 单一职责原则
单一职责原则(Single Responsibility Principle，SRP)指出，每个方法或类应当有且仅有
一个改变的理由。这意味着每个方法或类应当做一件事情，或者只有一项职责。在所有的
SOLID原则中，这是大多数开发人员感到最能完全理解的一条。严格来说，这也可能是违
反最频繁的一条原则了。
2. 开放/ 封闭原则
1) 简述：软件实体，比如说类，模块，功能等，应当为扩展开放，但是对修改关闭，什么意思呢？就是说，在一个现有的工程完毕之后，以后所有的新添加的功能应当在不修改原有代码的基础上进行，不应当在已有的代码上进行任何的代码修改或者逻辑的修改添加操作。
2) 如何遵守开放-封闭原则
实现开放-封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，这样的修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。
a.在设计方面充分应用“抽象”和“封装”的思想。
一方面也就是要在软件系统中找出各种可能的“可变因素”，并将之封装起来；
另一方面，一种可变性因素不应当散落在多个不同代码模块中，而应当被封装到一个对象中。
b.在系统功能编程实现方面应用面向接口的编程。
当需求发生变化时，可以提供该接口新的实现类，以求适应变化。
面向接口编程要求功能类实现接口，对象声明为接口类型。在设计模式中，装饰模式比较明显地用到了OCP。
3）例子
以播放器为例，先定义一个抽象的接口，代码如下所示。
interface process{
public function process();
}
然后，对此接口进行扩展，实现解码和输出的功能，如代码清单2-10所示。
代码清单2-10 实现播放器的编码功能
class playerencode implements process{
public function process(){
echo "encode＼r＼n";
}
}
class playeroutput implements process{
public function process(){
echo "output＼r＼n";
}
}
3. 里氏替换原则
继承对于OCP，就相当于多态性对于里氏替换原则(Liskov Substitution Principle，LSP)。
LSP 规定：用超类代替应用程序中使用的对象时，应当不会破坏应用程序。这通常也被称
为“契约式设计(design by contract)”。
回想前面的多态性示例，ComputePay 方法使用了Employee 类型的列表，其中Employee
就是基类型(超类型)。Salary、Hourly 和Seasonal 类都是从Employee 继承而来，因此它们
是Employee 的子类型。
根据LSP，即使已经将列表声明为Employee 的列表，也仍然可以用Salary、Hourly
和Seasonal 的具体实例来填充它。因为有了继承，它们都支持Employee 声明的相同契约(公
共的方法集或API)。应用程序可以对该列表进行迭代，并调用那些在列表中各个项目的
Employee 上定义的方法，不需要知道或特别关心它们都是什么类型。如果它们支持契约，
该调用就是合法的。
4. 接口分离原则
1）概述
当我们设计程序的时候，我们应当关心如何设计一个包含了若干子模块的父类。 假如现在我们有一个模块继承自一个父类，而这个父类是一个接口。单单对这个模块来说，一切够用。但是如果我们添加其他的模块，也继承自这个接口，那么我们将不得不实现接口中的所有的方法，这种接口就被称作富余接口，这种设计是不被赞赏的。
所以这也是接口分离原则产生的原因。所谓的接口分离原则就是指子模块不必继承并实现父模块中不需要的东西。所以，对于富余接口来说，多创建一些分类明确，职责单一的小接口是正确的做法。
5. 依赖倒置原则
在完美世界里，应用程序的组件之间没有耦合关系或绑定关系。开发人员也能够改变
自己希望改变的任何东西，而不需要担心在应用程序的其他地方出现缺陷，或者“不希望
存在的负面影响”。令人悲伤的是，我们并不是生活在完美世界里。因此，组件需要相互
绑定在一起，或者在某一点耦合，以构成实际应用程序。
依赖倒置原则(Dependency Inversion Principle，DIP)规定：代码应当取决于抽象概念，
而不是具体实现；这些抽象不应当依赖于细节；而细节应当依赖于抽象。类可能依赖于其
他类来执行其工作(Employee 服务可能依赖于数据访问组件向数据存储中保存和检索员工
信息)。但是，它们不应当依赖于该类的特定具体实现，而应当是它的抽象。也就是说，
Employee 服务不知道(或不关心)正在使用哪个具体的数据访问组件——只有它的抽象或代
码契约(或接口)支持那些用于保存和检索员工所需要的方法。
显然，这一概念会大大提高系统的灵活性。如果类只关心它们用于支持特定契约而不
是特定类型的组件，就可以快速而轻松地修改这些低级服务的功能，同时最大限度地降低
对系统其余部分的影响。在第6 章，还会看到如何利用这一概念来模拟这些依赖项，以进
行测试。有时，需要向类中提供这一低级服务的具体实现，以便这个类能够完成自己的工
作。最常见的做法，特别是在.NET 中使用TDD 的开发人员，就是依赖项注入(DI)模式。