六大设计原则（总结）

设计原则只是原则，是一个编程的大方向，在实际编程中，并不会时时刻刻一点也不违背，会因时因地灵活对待。只是遵守这些原则，会方便后续程序的开发与维护。

1. 单一职责原则

单一职责原则（Single Responsibility Principle，SRP），定义是：应该有且仅有一个原因引起类的变更。

注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

2.里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP），定义是：所有引用基类的地方必须能透明地使用其子类的

对象。包含4层含义：

• 子类必须完全实现父类的方法
• 子类可以有自己的个性，即方法和属性
• 覆盖或实现父类的方法时输入参数可以被放大
• 覆写或实现父类的方法时输出结果可以被缩小

3.依赖倒置原则

依赖倒置原则（Dependence Inversion Principle，DIP），包含三层含义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化。

依赖倒置原则在Java语言中的表现就是：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
• 接口或抽象类不依赖于实现类；
• 实现类依赖接口或抽象类。

更加精简的定义就是“面向接口编程”。

4.接口隔离原则

有两种定义：客户端不应该依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上。

第一种定义：“客户端不应该依赖它不需要的接口”，那依赖什么？依赖它需要的接口，客户端需要什么接口就提什么接口，把不需要的接口剔除掉，那就需要对接口进行细化，保证其纯洁性；

再看第二种定义：“类间的依赖关系应该建立在最小的接口上”，它要求是最小的接口，也是要求接口细化，接口纯洁，与第一个定义如出一辙，只是一个事物的两种不同描述。

概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

接口隔离原则是对接口进行规范约束，其包含以下4层含义：

• 接口要尽量小 ；这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度

  的

• 接口要高内聚 ；高内聚就是提高接口、类、模块的处理能力，减少对外的交互。

• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

5.迪米特法则

迪米特法则（Law of Demeter，LoD），也称为最少知识原则（Least Knowledge Principle，LKP）：一个对象应该对其他对象有最少的了解。

通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义：

• 只和朋友交流

只与直接的朋友通信。什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。

• 朋友间也是有距离的

一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。

• 是自己的就是自己的

一个方法，放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

• 谨慎使用Serializable

6.开闭原则

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

软件实体包括：项目或软件产品中按照一定的逻辑规则划分的模块；抽象和类；方法。

一个软件产品只要在生命期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

开闭原则是最基础的一个原则，前五个原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖。