一、什么是设计模式?
设计模式是一种思想,是一套被反复使用、多数人知晓的、经过分类编写、代码设计经验的总结。
用自己的话说就是:设计模式是一种经验的总结/沉淀,在不同场景下,编程的最佳实践经验总结。
设计模式解决什么问题?
解决代码的可扩展性、可重用性、可读/可维护
公司一般都需要走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即可。
优点
这种情况如果加新的扩展,上图中核心的主体不用动,只需要在下图中添加自己新的逻辑,不需要关注其他人的逻辑,解耦了(开发时不去改别人的东西)