【博学谷学习记录】超强总结，用心分享|架构师-设计模式 1

一、什么是设计模式？

设计模式是一种思想，是一套被反复使用、多数人知晓的、经过分类编写、代码设计经验的总结。
用自己的话说就是：设计模式是一种经验的总结/沉淀，在不同场景下，编程的最佳实践经验总结。

设计模式解决什么问题？
解决代码的可扩展性、可重用性、可读/可维护

公司一般都需要走code review（代码审查）

二、SOLID原则

一共分五种原则：

理解为写代码的红线，不要违反
先介绍前两种

2.1 单一职责原则（SRP）

单一功能—一个类专一做某个事
问题：下面的类满不满足单一职责原则？ 具体要看场景

类的职责是否设计的越单一越好？也不是
比如序列化类：序列化和反序列化

2.2 开闭原则（OCP）

对于扩展是开放的，对于修改是封闭的

核心思想：面向抽象编程（即面向接口编程）
不要改变原有的核心的代码，即爆炸半径小（出事后，影响范围小）

怎么体现高内聚低耦合？例子：
需求：api接口，把不同维度的指标统计出来，根据不同指标以及对应的规则，来进行告警通知
重点是规则+通知
先看规则：

通知类：

告警类：
tps规则和错误次数来判断是否告警

当前哪个api，在多长时间内，错误次数传入，adaptiveAlert方法决定是否告警

问题：上图代码设计的合理吗？
代码能跑，但可扩展性差—后期加东西减东西不方便
if太多了，不应该这么加，比如加timeout，即添加超时控制的需求，又要加个if且增加新的参数，且要添加对应规则

哪不合理？
1、方法加形参，影响很大，改起来很繁琐；
2、加if，添加新逻辑，要重新测试之前的功能，并且该方法变更很频繁，并不能保证每个人都清楚里面的所有逻辑（不同逻辑耦合在一块了）。
怎么优化？
步骤1、参数抽取
抽取到一个类ApiInfo中；
步骤2、共同的地方抽象成一个公共handler，不同的维度抽象成不同的handler（抽象类或抽象方法），先写抽象类，再写具体的Handler方法；
步骤3、主体方法加载handler即可。
优点
这种情况如果加新的扩展，上图中核心的主体不用动，只需要在下图中添加自己新的逻辑，不需要关注其他人的逻辑，解耦了（开发时不去改别人的东西）