六大设计模式原则

1 单一职责原则

(Single Responsibility Principle, SRP),有且仅有一个原因引起类的变更
顾名思义:一个类只负责一项职责

基本介绍
即对类来说,一个类应该只负责一项职责。如类 A 负责两个不同职责:职责 1,职责 2,当职责 1 需求变更而改变 A 时,可能造成职责 2 执行错误,所以需要将类 A 的粒度分解为 A1,A2

在这里插入图片描述
如何遵守单一职责原则?
其实就是合理的职责分解,
从业务出发,从需求出发,识别出同一个类型的职责
需要说明一点:单一职责原则不是面向对象语言特有的,只要是模块化的程序设计,都要遵守单一职责原则

2 接口隔离原则

(Interface Segregation Principle),又称为ISP原则,官方定义为:

Clients should not be forced to depend upon interfaces that they don’t use.
(客户端不应该依赖它不需要的接口)
The dependency of one class to another one should depend on the smallest possible
interface. (类间的依赖关系应该建立在最小的接口上)

基本介绍
通俗的来讲,不要在一个接口里面定义过多的方法,接口应该尽量细化。
接口隔离原则就是当我一个类通过接口依赖(使用)另一个类的时候,要保证依赖的该接口是最小的,
接口里面有方法用不到的,就进行隔离,而隔离的做法就是,就对原来接口进行拆分,拆分为最小粒度,来避免耦合

与单一职责原则对比

  • 单一职责原则:合理的职责分解,一个类只负责一项职责
  • 接口隔离原则:类间的依赖关系应该建立在最小的接口上

相同点
都要求对结构进行拆分,都要求更小的粒度,都希望减少耦合

不同点
审视角度的不同

单一职责原则:类与接口职责单一,注重的是职责
接口隔离原则:要求我们尽量使用多个专门的接口,注重的是接口的设计

我们使用接口隔离原则进行接口拆分的时候,要遵循单一职责原则

3 依赖倒转原则

其实我们在实际的开发中大部分都是遵守依赖倒转原则。即面向接口编程,习惯成自然,不知所以然。通过这个分析明确出来,以后写代码时就明白了为什么这样写,同时就会有意的去遵守这些看似简单但却很重要的设计模式原则,降低耦合提高代码质量。

官方定义

  • 依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,官方定义为:
    High level modules should not depend upon low level modules. Both should depend upon abstractions.
    (上层模块不应该依赖底层模块,它们都应该依赖于抽象)
    Abstractions should not depend upon details. Details should depend upon abstractions.
    (抽象不应该依赖于细节,细节应该依赖于抽象)

基本介绍

何为抽象? —> 接口或者抽象类
何为细节?—> 实现类
换句话说 依赖倒转原则核心的理念 相对于细节来说,抽象要稳定得多
要求我们 面向接口编程
java中抽象类和接口的目的就是制定好规范,不会涉及具体的操作 展现细节或者实现具体的业务逻辑,这些是要交给对应的实现类来解决的、换句话说抽象类和接口的价值就在于设计
总结: 依赖倒转原则其实就是要求我们面向接口编程,其实就是要求我们在编码的时候注意抽象类和接口的设计

4 里氏替换原则

里氏替换原则就是给继承性的使用制定了规范
里氏替换原则通俗的来讲:

子类可以扩展父类的功能,但是子类不能修改父类原有的功能 ;只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或者异常,使用者可能根本不需要知道是父类还是子类。但是反过来就不行了,有子类出现的地方,父类未必就能适应。

在这里插入图片描述

5 开闭原则

官方定义

开闭原则( Open Close Principle ),又称为OCP原则,他的官方定义如下:
Software entities like classes,modules and functions should be open for extension but closed for modifications.
一个软件实体如类,模块和函数应该对扩展开放,对修改关闭

基本介绍
针对调用方无任何修改,针对提供方是可以扩展的
对扩展开放 – 提供方
对修改关闭 – 调用方
就是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。那么什么是软件实体呢?软件实体包括一下几个部分:

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

6 迪米特法则

迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则(Least KnowledgePrinciple, LKP)
One object should have a minimum understanding of other objects
(一个对象应该对其他对象有最少的了解 )
Only talk to your immediate friends ( 只与直接的朋友通信)

基本介绍

什么是一个对象应该对其他对象有最少的了解?

换句话说,对于被依赖的类,不管多么复杂都应该将逻辑封装在类的内部,对外只提供公共的public方法,不对外泄露任何其他的信息。

什么是只与直接的朋友通信?
朋友关系: 只要两个对象有依赖关系那他们两个就是朋友关系

直接的朋友:

  • 成员变量

也就是说一个类以成员变量的形式出现在另一个类内部的那么这两个类互为直接的朋友

  • 方法的参数类型

也就是说一个类的方法接收的参数类型是另一个类的类型那么这两个类互为直接的朋友

  • 方法的返回值类型

也就是说一个方法中接收的返回值类型是另一个类的类型那么这两个类互为直接的朋友

比如说在方法内部使用到的,比如说这个类以局部变量的形式出现的,这种情况下他们就不是直接的朋友关系。

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/weixin_43811057/article/details/131534464