设计模式六大设计原则

最新推荐文章于 2020-07-14 10:25:30 发布

go_sparrow

最新推荐文章于 2020-07-14 10:25:30 发布

阅读量274

点赞数

本文链接：https://blog.csdn.net/java_sparrow/article/details/53443344

版权

设计模式专栏收录该内容

0 篇文章 0 订阅

订阅专栏

设计模式六大设计原则

单一职责原则

里氏替换原则

依赖倒置原则

接口隔离原则

迪米特法则

开闭原则

单一职责原则

单一职责原则（Single Responsibility Principe，简称SRP）

从字面上理解就是一个类只负责单一的职责，也就是功能单一。

那么问题来了，怎么来划分呢？划分的依据又是什么呢？

难点就在这里，并没有一个衡量的标准，具体的职责划分还需要根据实际情况来定，当然还有项目经理和客户。

一般基于RBAC（基于角色的访问控制Role Based Access Control）的角色管理类的模块，对角色的权限的管理，是操作和资源相分离。

单一职责：应该有且仅有一个原因引起类的变更

单一职责的好处

降低类的复杂度，每个类的职责清晰明确

提高可读性

提高可维护性

降低变更风险，如果没有做好单一职责，那么一个接口的变更将影响甚广，不利于系统的扩展

类的单一原则的实现是受多种因素的制约的，设计的时候需要考虑众多的因素

类的设计应尽量做到只有一个原因引起变化

里氏替换原则

面向对象的三大原则之一——继承Extends

减少代码的工作量

提高代码的重用性

提高代码的扩展性，子类继承父类

java中单一继承

里氏替换原则（Liskov Substitution Principle 简称LSP）

OCP作为OO的高层原则

主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构

维持设计的封闭性。

“抽象”是语言提供的功能。“多态”由继承语义实现的。

定义：

如果对每一个类型为S的对象O1，都有类型为T的对象O2，

使得以T定义的所有程序P在所有的对象O1都代换成O2时。

程序P的行为没有发生变化，那么类型S是类型T的子类型。

所有引用基类的地方必须能够透明使用其子类的对象

1、子类必须完全实现父类的方法（实现接口）

2、子类可以有自己特有的东西

3、覆盖或实现父类的方法时输入参数可以放大，（重载）

4、覆盖或实现父类的方法时输出结果可以被缩小

如果子类当做父类来用就需要剔除子类的特性，这样继承就没有意义了

依赖倒置原则

依赖倒置原则（Dependence Inversion Principe，DIP）

1、高层模块不应该依赖底层模块，两者都应该依赖其抽象

每一个逻辑实现都应该是由原子逻辑组成的，

底层模块就是不可分割的原子逻辑

高层模块就是原子逻辑的再组装

2、抽象不应该依赖细节

抽象就是指接口或抽象类，两者都不能被实例化

3、细节应该依赖抽象

细节就是实现类

实现接口、继承抽象类产生的类就是细节，可以被实例化，也就是加上new产生的对象

程序要依赖于抽象接口，不要依赖于具体实现。

简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，

这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题，

一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。

即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度

java中的应用

模块间的依赖通过抽象产生，实现类之间不能发生直接的依赖关系

其依赖是通过接口或者抽象产生的

接口或抽象类不依赖于实现类

实现类依赖接口或抽象类

说白了就是OOD（面向接口编程）

接口隔离原则

接口隔离原则（ISP--Interface Segregation Principle）

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

一个类对另一个类的依赖应该建立在最小的接口上

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

类继承的接口中的方法应该是至少用到一次的

接口分两种

实例接口：new一个对象时所使用的，在某种角度，java中类也是一种接口

类接口：interface关键字定义的接口

保证接口的纯洁性

接口隔离原则是对接口进行规范约束

1、接口尽量要小

首先不能违反单一职责原则。根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

2、接口要高内聚

高内聚就是提高接口、类、模块的处理能力，减少对外交互，具体的操作就是在接口中少公布public方法，接口是对外的承诺，承诺越少对系统开发越有利

3、定制服务

系统内的模块之间必然会有耦合，有耦合就存在相互访问的接口，所谓的定制服务就是单独为实现某个类设计的接口，避免出现该类不需要的功能实现。

4、接口设计师有限度的

接口设计粒度越小，系统越灵活。但是还要注意适度，避免接口复杂化，应减少开发难度，提高可维护性。

接口隔离原则是对接口的定义，某种角度也是对类的定义，接口和类尽量使用原子接口或原子类来组装。根据以下衡量规则

1、一个接口只服务于一个子模块或业务逻辑类

2、通过业务逻辑压缩接口中的public方法

3、已经污染的接口尽量去修改

4、了解具体的环境，拒绝盲从

实践、经验、领悟

迪米特法则

迪米特法则（Law of Demeter，LoD）也称最少知识原则（Least Knowledge Principle）

就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话

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

狭义的迪米特法则

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

朋友圈的确定

“朋友”条件：

1）当前对象本身（this）

2）以参量形式传入到当前对象方法中的对象

3）当前对象的实例变量直接引用的对象

4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友

5）当前对象所创建的对象

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”；否则就是“陌生人”。

狭义的迪米特法则的缺点：

在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。

遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

广义的迪米特法则在类的设计上的体现：

优先考虑将一个类设置成不变类。

尽量降低一个类的访问权限。

谨慎使用Serializable。

尽量降低成员的访问权限。（这段来自baidu）

1、只和朋友交流

一个类只和朋友类交流，不于陌生的类交流，类和类的关系是建立在类间而不是方法间，一个方法尽量不引入一个类中不存在的对象

2、即使是朋友类也不能距离太近（俩个刺猬相互取暖）

一个类的public属性、方法越多，修改设计的就越多，变更风险越大

3、是自己的就是自己的

一个方法放在本类中，既不增加类间的关系，对类不产生负面影响，那就放置在本类中。

迪米特法则的核心：

类间解耦、弱耦合，然后类的复用率才可以提高，这样就会产生大量的中间类。类间的解耦要有限度。设计时应该权衡项目，结构清晰，同时做到高内聚，低耦合。（六度分隔理论）