本文转载自 《面向对象设计原则》。为提高阅读效率，在原文基础上做了删减与部分示例代码的修改。
开闭原则
定义
勃兰特·梅耶在其1988年的著作《面向对象软件构造》中提出了开闭原则（Open Closed Principle，OCP）经典定义：软件实体应当对扩展开放，对修改关闭。
通俗来讲，就是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
实现方法
主要是通过“抽象约束、封装变化”来实现开闭原则。
【例】windows的桌面主题设计
主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的。
作用
- 提升可维护性
- 提升可复用性
- 降低测试成本：只需要测新增的代码，老代码可以不测
里氏替换原则
定义
里氏替换原则（Liskov Substitution Principle，LSP），是麻省理工学院计算机科学实验室的里斯科夫女士在1987年的“面向对象技术高峰会议”上发表的文章《数据抽象和层次》中提出的，具体是说：继承必须确保超类所拥有的性质在子类中仍然成立。
该原则阐述了什么时候应该使用继承，什么时候不应该，以及其中蕴含的原理。
通俗来讲，就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新的功能外，尽量不要重写父类的方法。
根据上述理解，对里氏替换原则的定义可以总结如下：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
- 子类中可以增加自己特有的方法
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
- 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等
实现方法
下面以“几维鸟不是鸟”为例来说明里氏替换原则。
鸟一般都会飞行，例如燕子的飞行速度是每小时120千米。但新西兰的几维鸟，由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行300千米要花费的时间。我们可能会如下设计：
程序代码如下：
public class LSPtest {
public static void main(String[] args) {
Bird bird1 = new Swallow();
Bird bird2 = new BrownKiwi();
bird1.setSpeed(120);
bird2.setSpeed(120);
System.out.println("如果飞行300公里：");
try {
System.out.println("燕子将飞行" + bird1.getFlyTime(300) + "小时.");
System.out.println("几维鸟将飞行" + bird2.getFlyTime(300) + "小时。");
} catch (Exception err) {
System.out.println("发生错误了!");
}
}
}
//鸟类
class Bird {
double flySpeed;
public void setSpeed(double speed) {
flySpeed = speed;
}
public double getFlyTime(double distance) {
return (distance / flySpeed);
}
}
//燕子类
class Swallow extends Bird {
}
//几维鸟类
class BrownKiwi extends Bird {
// 重写了父类的setSpeed方法
public void setSpeed(double speed) {
flySpeed = 0;
}
}
显然，拿燕子测试这段代码，结果正确。但如果拿几维鸟测试，结果会发生“除零异常”，明显不符合预期。
运行结果如下：
如果飞行300公里：
燕子将飞行2.5小时.
发生错误了!
程序运行错误的原因是：几维鸟类重写了鸟类的 setSpeed(double speed) 方法，这违背了里氏替换原则。正确的做法是：取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0，可以计算出其奔跑 300 千米所要花费的时间。其类图如下所示。
作用
- 是实现开闭原则的重要方式之一
- 客服了继承中重写父类造成的可复用性变差的缺点
- 保证类的扩展不会给已有系统引入新的错误，降低了代码出错的可能性
依赖倒置原则
定义
依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁于 1996 年在 C++ Report 上发表的文章。
其原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。
实现方法
下面以“顾客购物程序”为例来说明依赖倒置原则。
本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物：
class Customer {
public void shopping(ShaoguanShop shop) {
//购物
System.out.println(shop.sell());
}
}
但是，这种设计存在缺点，如果该顾客想从另外一家商店（如婺源网店 WuyuanShop）购物，就要将该顾客的代码修改如下：
class Customer {
public void shopping(WuyuanShop shop) {
//购物
System.out.println(shop.sell());
}
}
顾客每更换一家商店，都要修改一次代码，这明显违背了开闭原则。存在以上缺点的原因是：顾客类设计时同具体的商店类绑定了，这违背了依赖倒置原则。解决方法是：定义“婺源网店”和“韶关网店”的共同接口 Shop，顾客类面向该接口编程，其代码修改如下：
class Customer {
public void shopping(Shop shop) {
//购物
System.out.println(shop.sell());
}
}
这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类图如下所示。
作用
- 降低类间的耦合性
- 提高系统的稳定性
- 减少并行开发引起的风险
- 提高代码的可读性和可维护性
单一职责原则
定义
单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
如果一个对象承担了太多的职责，至少存在以下两个缺点：
- 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力
- 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费
实现方法
注意：单一职责同样适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。
我们以业务场景中常见的“变量的三级缓存”为例。假设有一个布尔型变量，它有内存缓存、文件缓存、网络缓存3级缓存，我们为其设计一个get方法以获取其值，为了提高性能，顺序为“内存缓存 → 文件缓存 → 网络缓存”。
如果我们只提供一个get方法，其中实现了所有的业务逻辑：
private Boolean ecrCache;
public boolean getEcr() {
// 检查内存缓存
if (ecrCache != null) {
return ecrCache.booleanValue();
}
// TODO 获取文件缓存并赋值给ecrFromFile变量
Boolean ecrFromFile;
if (ecrFromFile != null) {
ecrCache = ecrFromFile;
return ecrFromFile;
}
// TODO 请求网络获取ecr的值并赋值给ecrFromNet变量
Boolean ecrFromNet;
if (ecrFromNet != null) {
ecrCache = ecrFromNet;
// TODO ecrFromNet写入文件缓存中
return ecrFromNet;
}
return ecrCache;
}
上述伪代码中每一个“TODO”都对应一段代码，这样的设计是非常糟糕的，后续的需求变更会非常困难，而且代码也很难复用。
优秀的设计应该是细化业务粒度，为每种缓存获取都独立出一个方法，最后由再由get方法统一组装调度：
private Boolean ecrCache;
public boolean getEcr() {
// 检查内存缓存
if (ecrCache != null) {
return ecrCache.booleanValue();
}
Boolean ecrFromFile = readFromFile();
if (ecrFromFile != null) {
ecrCache = ecrFromFile;
return ecrFromFile;
}
Boolean ecrFromNet = getEcrFromNet();
if (ecrFromNet != null) {
ecrCache = ecrFromNet;
writeToFile(ecrFromNet);
return ecrFromNet;
}
return ecrCache;
}
private Boolean readFromFile() {
// TODO 获取文件缓存
}
private void writeToFile(Boolean value) {
// TODO ecrFromNet写入文件缓存中
}
private Boolean getEcrFromNet() {
// TODO 请求网络获取ecr的值
}
独立出这些私有方法后，后续还能随意组装成新的get方法，代码也能简单复用。
作用
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。它有以下作用：
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
- 提高类的可读性。复杂性降低，自然其可读性会提高。
- 提高系统的可维护性。可读性提高，那自然更容易维护了。
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
接口隔离原则
定义
接口隔离原则（Interface Segregation Principle，ISP）是罗伯特·C.马丁于2002 年提出的，他指出：客户端不应该被迫依赖于它不使用的方法。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上。
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。因此，接口隔离原则要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
- 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
- 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
实现方法
在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
- 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
- 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
- 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
下面以学生成绩管理程序为例介绍接口隔离原则的应用。
学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能，如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中，其类图如下：
示例代码：
public class ISPtest {
public static void main(String[] args) {
InputModule input = StuScoreList.getInputModule();
CountModule count = StuScoreList.getCountModule();
PrintModule print = StuScoreList.getPrintModule();
input.insert();
count.countTotalScore();
print.printStuInfo();
//print.delete();
}
}
//输入模块接口
interface InputModule {
void insert();
void delete();
void modify();
}
//统计模块接口
interface CountModule {
void countTotalScore();
void countAverage();
}
//打印模块接口
interface PrintModule {
void printStuInfo();
void queryStuInfo();
}
//实现类
class StuScoreList implements InputModule, CountModule, PrintModule {
private static StuScoreList instance;
private StuScoreList() {
}
public static InputModule getInputModule() {
if (instance == null) {
instance = new StuScoreList();
}
return (InputModule) instance;
}
public static CountModule getCountModule() {
if (instance == null) {
instance = new StuScoreList();
}
return (CountModule) instance;
}
public static PrintModule getPrintModule() {
if (instance == null) {
instance = new StuScoreList();
}
return (PrintModule) instance;
}
public void insert() {
System.out.println("输入模块的insert()方法被调用！");
}
public void delete() {
System.out.println("输入模块的delete()方法被调用！");
}
public void modify() {
System.out.println("输入模块的modify()方法被调用！");
}
public void countTotalScore() {
System.out.println("统计模块的countTotalScore()方法被调用！");
}
public void countAverage() {
System.out.println("统计模块的countAverage()方法被调用！");
}
public void printStuInfo() {
System.out.println("打印模块的printStuInfo()方法被调用！");
}
public void queryStuInfo() {
System.out.println("打印模块的queryStuInfo()方法被调用！");
}
}
程序运行结果为：
输入模块的insert()方法被调用！
统计模块的countTotalScore()方法被调用！
打印模块的printStuInfo()方法被调用！
作用
接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点：
- 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
- 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
- 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
- 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
- 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
迪米特法则
定义
迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，由伊恩·荷兰（Ian Holland）于 1987 年美国东北大学的一个名为迪米特的研究项目中提出。迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
实现方法
我们以“明星与经纪人的关系”为例。明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如下：
程序代码：
public class LoDtest {
public static void main(String[] args) {
Agent agent = new Agent();
agent.setStar(new Star("林心如"));
agent.setFans(new Fans("粉丝韩丞"));
agent.setCompany(new Company("中国传媒有限公司"));
agent.meeting();
agent.business();
}
}
//经纪人
class Agent {
private Star myStar;
private Fans myFans;
private Company myCompany;
public void setStar(Star myStar) {
this.myStar = myStar;
}
public void setFans(Fans myFans) {
this.myFans = myFans;
}
public void setCompany(Company myCompany) {
this.myCompany = myCompany;
}
public void meeting() {
System.out.println(myFans.getName() + "与明星" + myStar.getName() + "见面了。");
}
public void business() {
System.out.println(myCompany.getName() + "与明星" + myStar.getName() + "洽淡业务。");
}
}
//明星
class Star {
private String name;
Star(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
//粉丝
class Fans {
private String name;
Fans(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
//媒体公司
class Company {
private String name;
Company(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
运行结果为：
粉丝韩丞与明星林心如见面了。
中国传媒有限公司与明星林心如洽淡业务。
作用
迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。
- 降低了类之间的耦合度，提高了模块的相对独立性。
- 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
合成复用原则
定义
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
实现方法
以“汽车分类管理程序”为例。汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继承关系实现的汽车分类的类图。
可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如下所示。
总结
实际上，这些原则的目的只有一个：降低对象之间的耦合，增加程序的可复用性、可扩展性和可维护性。
| 设计原则 | 一句话归纳 | 目的 |
|---|---|---|
| 开闭原则 | 对扩展开放，对修改关闭 | 降低维护带来的新风险 |
| 依赖倒置原则 | 高层不应该依赖低层，要面向接口编程 | 更利于代码结构的升级扩展 |
| 单一职责原则 | 一个类只干一件事，实现类要单一 | 便于理解，提高代码的可读性 |
| 接口隔离原则 | 一个接口只干一件事，接口要精简单一 | 功能解耦，高聚合、低耦合 |
| 迪米特法则 | 不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度 | 只和朋友交流，不和陌生人说话，减少代码臃肿 |
| 里氏替换原则 | 不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义 | 防止继承泛滥 |
| 合成复用原则 | 尽量使用组合或者聚合关系实现代码复用，少使用继承 | 降低代码耦合 |