【设计模式】一文理解记住设计模式的原则

️前言

本文只针对用几分钟快速了解设计模式的原则，更详细请查找更多资料

单一职责原则

1. 定义

她规定一个类应该只有一个发生变化的原因

2. 定义很抽象，咱继续看

单一职责原则强调职责的分离，就是一个类只能负责一种职责行为

3. 举几个栗子

• SpringBoot的Main类，只有一个职责——启动项目
• SpringMVC的Controller层，Service层，DAO层划分不同的职责
• UserController对应一个职责——对用户相关职责
• UserController的登录功能也可以分离成一个类——对应单一的登录职责

4. 以上栗子出现了一个问题，单一职责的划分究竟可以分多细

• 规矩是人定的，符号业务需求就好
• 一个用户控制类可以划分出登录类负责单一登录职责，需要看需求而定，如果登录方式有QQ,微信等多种方式，单独划分出登录控制类是合理的，但是如果只有一个账号密码登录方法，将其划分出来是否显得多余。

5. 怎么记住这个原则

• 最典型的代表——记住SpringBoot的主函数是单一职责原则，看到他就想起:单一职责原则

接口隔离原则

1. 是不是觉得这个"隔离"和上面单一职责的"划分"很像，隔离意味着划分，不是一样的东西吗?怎么区别两者的区别呢

• 单一职责原则是接口隔离原则的基础
• 单一职责原则注重从职责的角度进行类或接口的划分
• 在此基础上，接口隔离原则登场，注重接口使用的“精确性”和"最小化"
• 如果还是很迷惑，没事继续往下看

2.接口隔离原则主要体现在两个方面

2.1. 不要使用没有任何依赖关系的接口

• 简单来说就是不要使用那些完全没有必要实现的接口
• 举个JDK源码的栗子——JDK的作者也犯过这个错

public static void main(String[] args){
    List<Object> list = Collections.emptyList();
    list.add(new Object());
}

我们执行这个代码会报错

为什么?

因为通过emptyList()创建的空集合是不支持add()方法的，但这不是重点，重点在于EmptyList对象实现了一个RandomAccess接口。

因为 EmptyList对象实现了一个RandomAccess接口 ，意味着 emptyList()空对象要支持随机访问，但是从这个 emptyList()创建到销毁都不能add()进去一个对象，有谈何随机访问呢? 那这个 RandomAccess接口 就是无意义的。
所以 RandomAccess接口 违反了接口隔离原则，所以JDK作者也会犯错哈哈(虽然无伤大雅)

• 所有再次强调接口隔离第一条原则: 不要使用没有任何依赖关系的接口

2.2 一个类对另一个类的依赖性应该建立在最小的接口上

• 简单理解就是把接口的按单一职责划分清楚，再给子类去实现使用
• 再用JDK的代码举个例子

上面就将接口划分为

• 支持随机访问
• 支持序列化

所有总的来说，这就是接口隔离，在单一职责原则的基础上，不使用没有依赖关系的接口，对接口进行更精确，细化的划分，从而达到接口隔离的境界。

3. 怎么记住这个原则

• 接口隔离就是把不要的接口去掉，把(细糠)接口按单一职责分好留下来
• 再次强调: 不要使用没有任何依赖关系的接口
• 再次强调: 一个类对另一个类的依赖性应该建立在最小的接口上

里氏替换原则

1. 定义

• 子类需要实现父类所有抽象方法——(其实你一定会这么做的,不然编译器就爆红了)
• 子类可以增扩自己的方法和属性
• 子类重载覆盖父类已实现的方法(我觉得这个没啥实际意义，可以忽略这条，在下方阐述原因)

2. 怎么记住他

• 里氏的氏，联想到父子
• 子承父业，子再发家
• 子类继承父类已有的方法，子类增加自己的属性和方法

3. 子类覆盖父类已实现的方法 ，我觉得没啥意义的原因

• 从业务的角度，子类覆盖父类已实现的方法，可以通过静态委派调用被重载的父类的方法，但是搞那么复杂干嘛，我想用子类调用方法直接在子类新增想要的方法就行了，想用父类的就直接用，何必搞个静态委派折磨人。

依赖倒置原则

1. 定义

就是面向接口编程

2. 怎么理解他

• 去搜一下面向接口编程，此处不赘述，简单理解就是对多态的运用。

3. 怎么记住他

• 依赖倒置就是从依赖具体的对象倒置成依赖抽象的接口

迪米特原则

1. 定义

• 最少知道原则

2. 怎么理解他

• 一个类对另一个类知道的越少越好，一个类只通过一个接口通信，但不会暴露内部细节给对方
• 类比客户端和服务器，只需要暴露一个接口，内部怎么实现不关心

️3. 怎么记住他

• 迪 和 低谐音，低就是少
• 即最少依赖原则

开闭原则

1. 定义

对修改关闭，对扩展开放

❤️2. 怎么理解

不用修改已有的类，只通过新增代码，达到添加功能的目的

3. 怎么记住他

• 对修改关闭，对扩展开放

设计模式的分类

此处不展开

创建型模式

• 工厂方法模式
• 抽象工厂模式
• 单例模式
• 建造者模式
• 原型模式

结构型模式

• 适配器模式
• 桥接模式
• 装饰模式
• 组合模式
• 外观模式
• 享元模式
• 代理模式

行为模式

• 策略模式
• 模版方法模式
• 观察者模式
• 迭代器模式
• 责任链模式
• 命令模式
• 备忘录模式
• 状态模式
• 访问者模式
• 中介者模式
• 解释器模式

~理解有限，有错再补