01. 0.设计模式的7大原则-优快云博客

7大原则,23种设计模式
使用设计模式的目的:低耦合性,高内聚性,可维护性,可扩展性,重用性,灵活性

低耦合性,高内聚性:模块内部很紧密,模块和模块之间,联系不大.比如A-B模块,如果A出了问题,不把问题带入B模块.
重用性 : 相同的代码,不用多次编写
可扩展性 : 当需要增加新的功能时,非常的方便,
可靠性 : 当我们增加新的功能时,对原来的功能没有影响

1. 单一职责原则

基本介绍

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

总结

单一职责原则注意事项和细节

降低类的复杂度，一个类只负责一项职责。
提高类的可读性，可维护性
降低变更引起的风险
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违
反单一职责原则;只有类中方法数量足够少，可以在方法级别保持单一职责原则

单一职责就是一个类只干一种类型的活,如订单类,就只干和订单相关的活,和订单相关的客户类就不需要关心了.

2. 接口隔离原则

基本介绍

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

在这里插入图片描述

改进

类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口 Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法。
按隔离原则应当这样处理: 将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

总结

使接口不要有多余的方法.如果有多余的方法,那么实现类也就要有多余的方法来实现接口

3. 依赖倒转原则(Dependence Inversion Principle)

基本介绍

高层模块不应该依赖低层模块,二者都应该依赖其抽象.
抽象不应该依赖细节,细节应该依赖抽象
依赖倒转(倒置)的中心思想是面向接口编程
依赖倒转原则是基于这样的设计理念 :

相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在java中,抽象指的是接口或抽象类,细节就是具体的实现类.

使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成

例子

比如组装一个电脑,需要硬盘,cpu,内存等硬件
而不是具体到某品牌的硬盘,cpu,内存等硬件
在具体实现组装电脑细节的时候,再去选择具体的品牌

改进

只要抽象的接口不变, 具体使用时就可以替换任意品牌,客户程序不需要变化

总结

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

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

4. 里氏替换原则

告诉我们继承时需要遵守什么规则

OO中的继承性的思考和说明

继承包含这样一层含义:

父类中凡是已经实现好的方法,实际上是在设定规范和契约
虽然不强制要求所有的子类都必须遵循这些契约,饭如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏.

继承在给程序设计带来便利的同事,也带来了弊端.

比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其它的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到的子类都有可能产生故障

基本介绍

如果对每个类型为T1的对象O1,都有类型为T2的对象O2,使得以T1定义的所有程序P在所有的对象O1都带换成O2时,那么类型T2是类型T1的子类型.换句话说,所有引用基类的地方必须透明地使用其子类的对象

O2都继承了O1的方法,且没有修改过O1的方法

在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
继承实际上让两个类的耦合性增加了,在适当的情况下,可以通过聚合,组合,依赖,来解决问题

总结

任何基类可以出现的地方,子类一定可以出现.
也即是说,子类可以扩展父类的方法,但是不能改变父类原有的方法(别重写父类的方法)

5. 开闭原则(Open Closed Principle)

基本介绍

开闭原则(Open Closed Principle)是编程中最基础,最重要的设计原则.
一个软件实体,如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节.

提供方可以增加,一些方法.使用方可以保持不变,不用修改

当软件需要变化时,尽量通过扩展软件实体来实现变化,而不是通过修改已有的代码来实现变化
编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则

总结

对扩展开放,对修改关闭.
为了达到这样的效果,我们需要使用接口和抽象类

因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定.
而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时只需要根据需求重新派生一个实现类来和扩展就可以了

6.迪米特法则

基本介绍

一个对象应该对其它对象保持最少得了解
类与类关系越密切,耦合度越大
迪米特法则(Demeter Principle)又叫最少知道原则

一个类对自己所依赖的类知道的越少越好,也就是说,对于被依赖的类不管多复杂,都尽量将逻辑封装在类的内部,对外除了提供public方法,不对外泄露任何信息

迪米特法则还有个更简单的定义 : 只与直接朋友通信

每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系.耦合的方式很多,依赖,关联,组合,聚合等.

直接朋友 :我们称出现成员变量,方法参数,方法返回值中的类为直接朋友
而出现在局部变量中的类不是直接朋友,也就是说,陌生的类最要不要以局部变量的形式出现在类的内部.(要做什么在自己的类中做完,不要在别人的类中去实现细节)