JAVA设计模式——七大设计原则

 

 设计原则核心思想

1) 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代

码混在一起。

2) 针对接口编程，而不是针对实现编程。

3) 为了交互对象之间的松耦合设计而努力

常用的七大原则

1. 单一职责原则
2. 接口隔离原则
3. 依赖倒转原则
4. 里氏替换原则
5. 开闭原则 ocp
6. 迪米特法则
7. 合成复用原则

  单一职责原则

对类来说的， 即一个类应该只负责一项职责 。如类 A 负责两个不同职责：职责 1 ，职责 2 。

当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为

A1 ， A2

单一职责原则注意事项和细节

1) 降低类的复杂度，一个类只负责一项职责。

2) 提高类的可读性，可维护性

3) 降低变更引起的风险

4) 通常情况下， 我们应当遵守单一职责原则 ，只有逻辑足够简单，才可以在代码级违

反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

 接口隔离原则 (Interface Segregation Principle)

基本介绍

1) 客户端不应该依赖它不需要的接

口，即 一个类对另一个类的依赖

应该建立在最小的接口上

2）

应传统方法的问题和使用接口隔离原则改进

1) 类 A 通过接口 Interface1 依赖类 B ，类 C 通过接口 Interface1 依赖类 D ，如果接口

Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 必须去实现他们不

需要的方法

2) 将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立

依赖关系。也就是采用接口隔离原则

3) 接口 Interface1 中出现的方法，根据实际情况拆分为三个接口

 

 依赖倒转原则

基本介绍

依赖倒转原则 ( Dependence Inversion Principle ) 是指：

1) 高层模块不应该依赖低层模块，二者都应该依赖其抽象

2) 抽象不应该依赖细节，细节应该依赖抽象

3) 依赖倒转 ( 倒置 ) 的 中心思想是面向接口编程

4) 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的

多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象

指的是接口或抽象类，细节就是具体的实现类

5) 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的

任务交给他们的实现类去完成

依赖倒转原则的注意事项和细节

1) 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好 .

2) 变量的声明类型尽量是抽象类或接口 , 这样我们的变量引用和实际对象间，就存在

一个缓冲层，利于程序扩展和优化

3) 继承时遵循里氏替换原则

  里氏替换原则

基本介绍

1) 里氏替换原则 ( Liskov Substitution Principle ) 在 1988 年，由麻省理工学院的以为姓里

的女士提出的。

2) 如果对每个类型为 T1 的对象 o1 ，都有类型为 T2 的对象 o2 ，使得以 T1 定义的所有程序

P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1

的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

3) 在使用继承时，遵循里氏替换原则，在子类中 尽量 不要重写父类的方法

4) 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了， 在适当的情况下，可

以通过聚合，组合，依赖 来解决问题

OO 中的继承性的思考和说明

1) 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契

约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实

现的方法任意修改，就会对整个继承体系造成破坏。

2) 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵

入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，

则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子

类的功能都有可能产生故障

3) 问题提出：在编程中，如何正确的使用继承 ? => 里氏替换原则

解决方法

1) 我们发现原来运行正常的相减功能发生了错误。原因就是类 B 无意中重写了父类的

方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完

成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运

行多态比较频繁的时候

2) 通用的做法是：原来的父类和子类都继承一个更通俗的 基类 ，原有的继承关系去掉，

采用依赖，聚合，组合等关系代替

 开闭原则

开闭原则是指在进行面向对象设计中，设计类或其他程序单位时，应该遵循：

• 对扩展开放（open）
• 对修改关闭（closed） 的设计原则。

• 开闭原则的实现方法
  为了满足开闭原则的对修改关闭原则以及扩展开放原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；

• 
  接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现；
  模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
  接口可以被复用，但接口的实现却不一定能被复用。
  接口是稳定的，关闭的，但接口的实现是可变的，开放的。
  可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔性扩展。

• 好处：提高系统的可复用性和可维护性。

  简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。
   

  迪米特法则

基本介绍

1) 一个对象应该对其他对象保持最少的了解

2) 类与类关系越密切，耦合度越大

3) 迪米特法则 ( Demeter Principle ) 又叫 最少知道原则 ，即一个类对自己依赖的类知道的

越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内

部。对外除了提供的 public 方法，不对外泄露任何信息

迪米特原则的初衷在于 降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

 合成复用原则（ Composite Reuse Principle ）

尽量使用组合/聚合，不要使用类继承。