2023-11-14
01 为什么学设计模式？
世上本没有路，走的人多了，便变成了路。在程序员的世界中，本没有设计模式，写代码是人多了，他们便总结出了一套能提高开发和维护效率的套路
360行干一行爱一行，作为一个搞技术的，手艺人，写的一手好代码是基本的职业需求，而设计模式是前辈们经验，反复总结、实践的方法，让我们少走弯路、少加班、提高效率。
那么，什么是好代码呢？
好代码
好代码通常都具备以下几个特性：
-
可维护性
在不去破坏原有的代码设计 , 能够快速的修改或者新增代码和功能。 -
可读性
代码是否符合编码规范、命名是否达意、注释是否详尽、模块划分是否清晰等。
常规的bad smell: 存在重复代码、过长的函数、过大的类、过多的分支、耦合过大的两个 class -
可扩展性
代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。 -
灵活性
是指在添加新代码的时候，已有代码能够不受影响，不产生冲突，不出现排斥，在保证自身不遭到破坏的前提下灵活地接纳新代码。
下面的几个场景,可以体现代码的灵活
- 添加新的功能代码时,原有代码已经预留了扩展点,我们不需要修改 直接在扩展点上新增代码即可.
- 当我们想实现一个功能模块时,发现原有代码中,已经抽象出了很多底层可以复用的模块、类等代码,我们可以直接拿来使用
- 当我们使用某组接口时,这组接口不用修改就可以应对各种使用场景,满足不同需求,这个接口设计的就十分的灵活易用.
-
简洁性
代码的写法应当使别人理解它所需的时间最小化, 要尽可能的简单；是思从深而行从简。 -
可测试性
通常写单元测试并不难，但有的时候，有的代码和功能难以测试，导致写起测试来困难重重。所以写出的代码具有可测试性，具有很重要的作用。
02 怎么学设计模式？
- 会看UML类图：所谓一图胜千言，它可以帮助我们在特定的场景下简单快速的了解类与类之间关系。
- 学而不用，毫无作用：作为一个过来人，建议新手一定要学而行之、用在自己开发的项目中，融会贯通。哪怕你是个CRUD工具人, 也看看项目现有的通用代码和工具类可以用用哪些设计模式。
UML 类图
03 设计模式概述
设计模式六原则
1.单一原则 （Single Responsibility Principle）
单一原则（Single Responsibility Principle）又称最少知道原则（Demeter Principle）, 迪米特原则, 是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
in short 一个类或者一个方法只负责一项职责，尽量做到类/方法只有一个行为
2.开闭原则（Open Close Principle）
开闭原则的意思是: 对扩展开放, 对修改关闭; 在程序需要进行拓展的时候, 不能去修改原有的代码, 实现一个热插拔的效果; 简言之, 是为了使程序的扩展性好, 易于维护和升级;
开闭原则是所有设计模式的最核心目标，所有的软件设计模式都应该以开闭原则当作标准，才能使软件更加的稳定和健壮。
顶层抽象设计思维
- 抽象意识, 从最上层开始定义接口
- 封装意识, 定义最基本抽象行为方法, (如果方法太多就要考虑是不是违背 单一职责)
- 扩展意识, 方法留下钩子, 或者多用 Lambda 作为形参, 也是个不错的主意.
in sort 策略模式, 命令模式, 就是典型的对扩展开放, 对修改关闭 的设计模式! 举一个在我所熟悉的物联网行业中, 物联网设备 与 平台的通讯, 设计应从上层开始考虑, 不考虑具体协议, 先考虑'消息' 这个抽象定义, 比如编解码, 加解密等
3.里氏替换原则（LSP liskov substitution principle）
里氏替换原则（LSP liskov substitution principle）: 只要有父类出现的地方，都可以用子类来替代，而且不会出现任何错误和异常. 更通俗点讲，就是子类可以扩展父类的功能，但是不能改变父类原有的功能。
in sort 记住这一点, 任何基类可以出现的地方, 子类一定可以出现;
4.接口隔离原则（Interface Segregation Principle）
这个原则的意思是: 接口的使用者, 不应该强迫依赖它不需要的接口, 使用多个隔离的接口, 比使用单个接口要好; 它还有另外一个意思是: 降低类之间的耦合度; 由此可见, 其实设计模式就是从大型软件架构出发, 便于升级和维护的软件设计思想, 它强调降低依赖, 降低耦合;
**in sort: 接口的使用者, 不应该强迫依赖它不需要的接口, 尽可能使用 '松散的', '多个接口的' 进行依赖开发; 当一个接口定义太多方法了, 则需要考虑是否符合该原则了
与依赖倒置原则有什么区别?
相对 依赖倒置原则 该原则更关注具体(抽象)方法的归类, 定义多个抽象的接口方法
5.依赖倒置原则（Dependence Inversion Principle）
所谓依赖倒置原则（Dependence Inversion Principle ）就是要依赖于抽象, 不要依赖于具体; 简单的说就是对抽象进行编程, 不要对实现进行编程, 这样就降低了客户与实现模块间的耦合;
上层调用下层 或者 上层依赖于下层时: 当下层剧烈变化时, 上层也要跟着变化, 这就会导致模块的复用性降低而且大大提高了开发的成本;
in sort 上层代码依赖下层代码时, 要针对接口/抽象编程, 不要针对实现编程, 避免组合强依赖的关系;
典型的就是 Controller层 > Service接口 > Service实现; 中间加一个Service 接口, 避免上层依赖下层
6.迪米特法则（Law of Demeter）
迪米特法则（LoD：Law of Demeter）又叫最少知识原则（LKP：Least Knowledge Principle ），指的是一个类/模块对其他的类/模块有越少的了解越好。
如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
**in short 迪米特法则想要表达的思想就是: 不该有直接依赖关系的类之间, 不要有依赖；有依赖关系的类之间, 尽量只依赖必要的接口
过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
设计模式分类
创建型 模式 (Creational Pattern)
创建型模式(Creational Pattern)对类的实例化过程进行了抽象, 能够将软件模块中对象的创建和对象的使用分离;
为了使软件的结构更加清晰, 外界对于这些对象只需要知道它们共同的接口, 而不清楚其具体的实现细节, 使整个系统的设计更加符合单一职责原则;
创建型模式在创建什么(What), 由谁创建(Who), 何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性; 创建型模式隐藏了类的实例的创建细节, 通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的;
in short: 隐藏 创建的细节 代码逻辑, 使 对象的创建 和 对象的使用 分离
常用的有：单例模式、工厂模式（工厂方法和抽象工厂）、建造者模式。
不常用的有：原型模式。
[[04.创建型 - 单例模式(Singleton Pattern)]]
[[05.创建型 - 简单工厂模式（Simple Factory Pattern)]]
[[06.创建型 - 工厂方法模式（Factory Method Pattern)]]
[[07.创建型 - 抽象工厂模式（Abstract Factory Pattern)]]
[[08.创建型 - 建造者模式 (Builder Pattern)]]
[[09.创建型 - 原型模式 (Prototype Pattern)]]
结构型 模式 (Structural Pattern)
结构型模式(Structural Pattern)描述 如何将类或者对象结合在一起形成更大的结构, 就像搭积木, 可以通过简单积木的组合形成复杂的, 功能更为强大的结构;
in short : 关注对象之间的组合和结构
[[10.结构型 - 代理模式 (Proxy Pattern)]]
[[11.结构型 - 桥接模式 (Bridge Pattern)]]
[[12.结构型 - 装饰模式 (Decorator Pattern)]]
[[13.结构型 - 适配器模式 (Adapter Pattern)]]
[[14.结构型 - 外观模式 (Facade Pattern)]]
[[15.结构型 - 组合模式 (Composite Pattern)]]
[[16.结构型 - 享元模式 (Flyweight Pattern)]]
行为型 模式 (Behavioral Pattern)
行为型模式不仅仅关注类和对象的结构, 而且重点关注它们之间的相互作用; 这些设计模式特别关注对象之间的通信;
行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。
行为型模型可以细分类两种: 1. 类行为型(继承); 2.对象行为型(组合); 除了模板方法模式和解释器模式是类行为型模式, 其他的全部属于对象行为型模式
[[17.行为型 - 观察者模式 (Observer Pattern)]]
[[18.行为型 - 模板方法模式(Template Method Pattern)]]
[[19.行为型 - 策略模式(Strategy Pattern)]]
[[20.行为型 - 责任链模式(ChainofResponsibility Pattern)]]
[[21.行为型 - 状态模式 (State Pattern)]]
[[22.行为型 - 迭代器模式 (Iterator Pattern)]]
[[23.行为型 - 访问者模式 (Visitor Pattern)]]
[[24.行为型 - 备忘录模式(History Pattern)]]
[[25.行为型 - 中介者模式 (Mediator Pattern)]]
[[26.行为型 - 命令模式 (Command Pattern)]]
[[27.行为型 - 解释器模式 (Interpreter Pattern)]]
in short : 重点关注对象之间的相互作用
常用的有：代理模式、桥接模式、装饰者模式、适配器模式。
不常用的有：门面模式、组合模式、享元模式。
