设计模式六大设计原则

客官°小女子只卖身不卖艺 2021-09-11 05:00 486阅读 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、是自己的就是自己的
> 
> 一个方法放在本类中，既不增加类间的关系，对类不产生负面影响，那就放置在本类中。
> 
> 迪米特法则的核心：
> 
> 类间解耦、弱耦合，然后类的复用率才可以提高，这样就会产生大量的中间类。类间的解耦要有限度。设计时应该权衡项目，结构清晰，同时做到高内聚，低耦合。（六度分隔理论）

# 开闭原则 #

开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。

对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。

对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

实现开闭原则的关键就在于“抽象”。

把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。

作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需修

由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。

开闭原则是一个基础原则，前面五个原则都是开闭的具体形态。

开闭为抽象，前五为实现类

1、抽象约束

通过接口或抽象类的约束扩展，对扩展进行边界限定