我是靠谱客的博主 会撒娇星月,最近开发中收集的这篇文章主要介绍[设计模式]-设计模式的设计原则以及目的前言设计模式常用的七大设计原则设计模式的目的,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

前言

参考视频链接

设计模式常用的七大设计原则

单一职责原则

对类来说的,一个类应该只负责一项职责

如果一个类负责两个职责,当其中一个职责需求变更而需要修改该类时,可能造成另一个职责执行出错,因此要分解该类

并不是要一味地分解类以实现单一职责原则,一味地分解类会导致类的数量过多,成本过大,也要考虑在一个类中,方法级别上去实现单一职责原则,当然,方法数也不能过多。

接口隔离原则

客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小的接口上

场景

一个接口 interface 中有五个方法,类 C 和类 D 实现了 interface 接口并且必须实现这五个方法,然后有类 A 通过 interface 依赖类 C,但类 A 只使用了 interface 中的方法 1,4,5;类 B 通过 interface 依赖类 D,但类 B 也只使用了 interface 中部的方法 1,2,3。这就造成了类 C 和 D 必须去实现他们不需要的方法的局面

按照原则我们应该这样处理:将 interface 拆分为独立的几个接口,类 A 和类 B 分别与他们需要的接口建立依赖关系。具体来说就是将 interface 拆分为三个接口,一个接口含有 1 方法,一个接口含有 4,5 方法,剩下一个接口含有 2,3 方法,然后让 C 去实现第一二个接口,D 去实现第一三个接口

依赖倒转原则

设计理念:相对于细节的多变性,抽象的东西要稳定得多;以抽象为基础搭建的架构比以细节为基础的架构要稳定得多,在 Java 中抽象可以说是接口与抽象类,其实现类就是细节。我们应该依赖于抽象,而不是依赖于具体

依赖关系三种传递方式:接口传递,构造方法传递,setter 方法传递

注意事项

  1. 低层模块尽量都要有抽象类或接口或者两者都有
  2. 变量的声明类型尽量是抽象类或接口这样使得变量引用和实际对象间存在一个缓冲层利于程序扩展和优化
  3. 继承时遵循里氏替换原则

里氏替换原则

关于 OO 中的继承性

  1. 继承的含义是,父类中已经实现好的方法,实际上是在设定规范和契约,虽然并不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏
  2. 继承的弊端在于,使用继承会给程序带来侵入性,程序的可移植性降低,对象间的耦合增加,如果一个类被其它的类继承,当这个类需要修改时必须考虑到所有子类,并且父类修改后所有涉及到子类的功能都有可能产生故障。所以,像 String 这样的核心类,是不允许被继承的

里氏替换原则的同理说法就是:所有引用基类的地方必须能透明地使用其子类的对象,或者说,当把父类引用指向父类对象改为指向子类对象时,程序的行为不会随之发生任何变化。这就要求,在使用继承时,在子类中尽量不要重写父类的方法

场景

假设现在有一个类 A,一个类 B,B 继承了 A 且重写了 A 中的方法,这时我们应该这样处理:
在 A 和 B 之上再创建一个基类,让 A 跟 B 都去继承这个基类,这样 A 和 B 之间做到了解耦,后续如果 B 还想调用 A 中的方法,可以用聚合,依赖,组合等方式实现,例如 B 中创建一个 A 类的成员变量,然后 B 类对象通过调用这个 A 变量去调用 A 中的方法

开闭原则 ocp (Open-Closed Principle)

开闭原则是编程中最基础最重要的设计原则,一个软件实体,如类,模块,或函数,应该 对扩展开放,对修改关闭。当软件需要变化时,尽量通过扩展软件实体的行为来实现变化而不是通过修改已有的代码来实现

框架应该要做到抽象,当我们实现时才扩展其细节

迪米特法则

又叫 最少知道原则,即一个类对自己所依赖的类知道的越少越好,也就是说,对于一个要被依赖的类,不管多么复杂,都尽量把逻辑封装在自己内部,对外除了提供 Public 方法,不提供任何信息

迪米特法则还有一个更简单的定义:只与直接的朋友通信。只要两个对象间有耦合关系,我们都称他们是朋友关系,耦合的方式有依赖,关联,组合,聚合等,其中我们称出现在成员变量,方法参数,方法返回值的类为直接的朋友,而出现在局部变量的类不是直接的朋友,也就是说陌生的类最好不要以局部变量的方式出现在类中

迪米特法则的核心是 降低耦合,并不是完全没有依赖

合成复用原则

尽量使用组合或聚合的方式,而不是继承

组合,如 A 有 B 参与组成,表现为 A 中含有 B 的全局对象 (局部变量),并且 B 在 A 创建时也 一起被创建 (在 A 中声明一个 B 类型的局部变量时使用 new 实例化;除此之外如果程序中 A 定义了对 B 的级联删除,那么此时 A 同样也是组合了 B)。整体和部分是不可以分开的

聚合,如 A 聚合了 B,表现为 A 中可以有 B 的引用,但 B 不在 A 创建的时候就创建,可能是通过 set 方法创建 (声明 B 类型的局部变量但只是声明没有赋值)。整体与部分是可以分开的。组合比聚合的耦合性更强,是否决定 被聚合/组合变量 的生命周期是两者的一大区别

设计模式的目的

  1. 代码重用性
  2. 可读性
  3. 可扩展性(可维护性)
  4. 可靠性
  5. 高内聚低耦合

最后

以上就是会撒娇星月为你收集整理的[设计模式]-设计模式的设计原则以及目的前言设计模式常用的七大设计原则设计模式的目的的全部内容,希望文章能够帮你解决[设计模式]-设计模式的设计原则以及目的前言设计模式常用的七大设计原则设计模式的目的所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(35)

评论列表共有 0 条评论

立即
投稿
返回
顶部