程序员的修仙之路——设计模式六大基本原则

简介: 程序员的修仙之路——设计模式六大基本原则

写在前面

Hello,你好呀,我是灰小猿!一个超会写bug的程序猿!

上一篇文章和大家介绍了在软件开发中常见的21种设计模式“程序媛妹妹让我教她养生。我竟然给她推荐了“设计模式之道”!”

想要学好设计模式,绝非是一天两天光理解概念就可以的,他需要你不断的在实践中去进行探索其中存在的真谛!所以今天就接着来和大家聊一下设计模式应该遵循的六大设计原则,

设计模式六大原则可以分为:

单一职责原则,实现类要职责单一;
里氏替换原则,不要破坏继承体系;
依赖倒置原则,要面向接口编程;
接口隔离原则,在设计接口的时候要精简单一;
迪米特原则,要降低耦合;
开闭原则,要对扩展开放,对修改关闭。

一、单一职责原则

单一职责原则定义:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。

单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。

单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

二、里氏替换原则

里氏代换原则(Liskov Substitution Principle, LSP)是指一个软件实体如果使用的是一个基类的话,那么-定适用于其子类,而且软件系统觉察不出基类对象和子类对象的区别,

也就是说,在软件系统中把基类都替换成它的子类,程序的行为没有变化。但需要注意的是,里氏代换原则中仅仅指出了用子类的对象去代替基类的对象,而反过来的代换则是不成立的。

例如,如果一个软件模块中使用的是一个子类对象,那么使用父类对象去代换子类对象则可能产生错误。

用一句简单的话概括:任何基类对象可以出现的地方,子类对象一定可以代替基类对象。

三、依赖倒置原则

依赖倒转原则(Dependence Inversion Principle,DIP) 就是要依赖于抽象,而不依赖于实现,或者说要针对接口编程,不要针对实现编程。

系统中进行设计和实现的时候应当使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型说明,以及数据类型的转换等,而不要用具体类进行上述操作。要保证做到这一点, 一个具体类应当只实现接口和抽象类中声明过的方法,而不要给出多余的方法。传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块,抽象层次依赖于具体层次。

依赖倒转原则就是把这个不良的依赖关系倒转过来。面向对象设计的重要原则是创建抽象层次,并且从该抽象层次导出具体层次,具体层次给出不同的实现。

继承关系就是一种从抽象化到具体化的导出。抽象层包含的应该是应用系统的业务逻辑和宏观的、对整个系统来说重要的战略性决定,而具体层次含有的是一些次要的与 实现有关的算法和逻辑,以及战术性的决定,带有一定的偶然性选择。从复用的角度来说,高层抽象的模块是应当复用的,而且是复用的重点,因为它含有一个应用系统最重要的宏观业务逻辑,是较为稳定的部分。而在传统的过程性设计中,复用则侧重于具体层次模块的复用。

使用依赖倒转原则时建议不依赖于具体类,即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到:任何变量都不应该持有-个指向具体类的指针或者引用;任何类都不应该从具体类派生;任何方法都不应该覆写它的任何基类中的己经实现的方法。

四、接口隔离原则

接口隔离原则定义:使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。

根据接口隔离原则,当一个接口太大时,我们需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干。这里的“接口”往往有两种不同的含义:一种是指一个类型所具有的方法特征的集合,仅仅是一种逻辑上的抽象;另外一种是指某种语言具体的“接口”定义,有严格的定义和结构,

五、迪米特法则

迪米特原则定义:迪米特法则(Law of Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。

也就是说:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

六、开-闭原则

开-闭原则(Open-Closed Principle) 是面向对象的可复用设计(Object Oriented Design,00D) 的基石。开-闭原则是指一个软件实体应当对扩展开放,对修改关闭,即在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展。

满足开-闭原则的系统可以通过扩展己有的软件系统,提供新的能力和行为,以满足对软件的新需求,使软件系统有一定的适应性和灵活性;

因为已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性;

满足开-闭原则的系统具备更好的可复用性与可维护性。在面向对象编程中,通过抽象类及接口,规定了具体类的特征作为抽象层,相对稳定,从而满足“对修改关闭”的要求;而从抽象类导出的具体类可以改变系统的行为,从而满足对扩展开放。

这六大设计原则是使用21种设计模式开发的基础,每一种设计模式的使用都应该尽可能的遵守这六大原则。

觉得有用记得点赞关注呀!

灰小猿陪你一起进步!

目录
相关文章
|
3月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
3月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
2月前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
5月前
|
设计模式 供应链
设计模式六大原则之迪米特法则
设计模式六大原则之迪米特法则
|
3月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
3月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
3月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
5月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
37 2
|
5月前
|
设计模式 Java 数据库
深入理解设计模式六大原则
深入理解设计模式六大原则
|
5月前
|
设计模式 数据可视化 程序员
设计模式学习心得之前置知识 UML图看法与六大原则(上)
设计模式学习心得之前置知识 UML图看法与六大原则(上)
42 0