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

news2024/9/22 11:30:16

目录——阅读所需预计5-10分钟

🎖️前言
- 🎯单一职责原则
- - 📣1. 定义
  - 💞2. 定义很抽象，咱继续看
  - 🎉3. 举几个栗子
  - 💞4. 以上栗子出现了一个问题，单一职责的划分究竟可以分多细
  - 👉5. 怎么记住这个原则
- 😜接口隔离原则
- - 😍1. 是不是觉得这个"隔离"和上面单一职责的"划分"很像，隔离意味着划分，不是一样的东西吗?怎么区别两者的区别呢
  - 🚀2.接口隔离原则主要体现在两个方面
  - - 🐴2.1. 不要使用没有任何依赖关系的接口
    - 🧐为什么?
    - 🙆2.2 一个类对另一个类的依赖性应该建立在最小的接口上
- 🐢3. 怎么记住这个原则
- 🍑里氏替换原则
- - 💌1. 定义
  - 🌈2. 怎么记住他
  - 🎽3. 子类覆盖父类已实现的方法，我觉得没啥意义的原因
- 📡依赖倒置原则
- - 😎1. 定义
  - 🙆2. 怎么理解他
  - 🤡3. 怎么记住他
- 😜迪米特原则
- - 💎1. 定义
  - 🔍2. 怎么理解他
  - 🎖️3. 怎么记住他
- 🎆开闭原则
- - 📣1. 定义
  - ❤️2. 怎么理解
  - 🎯3. 怎么记住他
设计模式的分类
- 创建型模式
- 结构型模式
- 行为模式

🎖️前言

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

🎯单一职责原则

📣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());
}

我们执行这个代码会报错
图片.png

🧐为什么?

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