每天学一个，设计模式概要

Posted 2020-12-31 fortunely

题外话

　　回想起大学学过一门课程《设计模式》，里面描述了很多包含前人思想精华的设计模式，用于构建代码。工作久了，虽然在写嵌入式C，但也经常能发现设计模式的精妙之处。而这些构建软件的思想，正是做底层软件的人经常所缺乏的思想，或者说，很少有软件复用、设计复用的意识。

　　比如，现在要设计一个定时器，用于计时，当计时时间满足条件时执行某项任务。假设硬件定时器中断1ms，任务定时1s，可以用uint32_t taskTimer（初值0） 来作软件定时器。

常规做法：

定义硬件定时器中断处理

// eTimer.c

extern uint32_t taskTimer;

// 硬件定时中断处理函数，1ms一次
interrupt void eTimerInterrupt()
{
    taskTimer ++;

　　// 清除中断...
    
}

 

查询软件定时器并执行任务

// main.c或者任务模块
#define TASK_TIME  1000

uint32_t taskTimer = 0;  //任务定时器

int main()
{
    while(1){
        if(taskTimer > TASK_TIME  ) {
            taskTimer = 0; // 清楚定时器

            //执行任务...

        }
    }
    return 0;
}

 

　　功能上，这个做法没有问题。但是，一旦项目的复杂度高，或者参与的人数多了，会让别人、甚至自己都看不懂，造成很大的困扰；如果应用层代码一旦有修改，比如换个变量名字，添加一个定时器，都需要修改底层。显然，这是不合理的。比较合理的做法是，底层应该是调用硬件驱动，给上层以接口形式提供服务，而不是强迫底层必须了解上层的细节，修改上层时也必须修改底层。

　　试想，如果操作系统不得不关注应用程序具体是如何使用某项功能的，而且应用的功能修改，操作系统底层必须修改，这种设计后果有多可怕。而处理这个问题有一个很不错的思路：就是将应用的定时器功能委托给底层硬件定时器模块，而底层只提供接口，不关注应用的使用细节。

没有经过封装的用法：

 

 

经过委托模式思想封装的用法：

 

参考

1. 设计模式六大原则 | 博客园

2. 设计模式六大原则

3. 设计模式六大原则 | CSDN

 

设计模式

总原则： 低耦合，高内聚；对扩展开放，对修改关闭。

 

六大原则

1. 单一职责原则

应该有且只有一个原因引起类的变化。简单来说，一个类负责一项职责，功能要单一。

场景：比如一个程序员既要负责编码，又要负责测试，那么编码出现问题的时候，就容易影响到测试；测试出问题的时候，就容易影响到编码。如果程序员只负责一项工作，那么就会，

优点：提高可扩展性、可维护性，降低类的复杂度。

 

2. 里氏替换原则

只要父类出现的地方，一定可以使用子类，而且不会出现任何异常。这样，使用者不需要知道是父类还是子类。

场景：商场为客户（人）提高购物场所，任何人都可以进去购物。如果非要针对每个人的职业、年龄、身体状况进行区分判断、对待，那么这个工作量无疑是巨大的。而且是不安全的，因为商场不得不针对实际情况修改验证规则。

优点：程序健壮性增强；即使增加不同子类，不影响原类运行。

 

3. 依赖倒置原则

高层模块不依赖底层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。

简而言之，对接口编程，而不是对实现编程。

场景：笔记本电脑虽然每个型号的充电插座端接口不一定相同，有TYPE-C的，有圆孔的，还有方口的，不过都会根据220V电源提供充电插头（接口），否则设计比较的时候按每个笔记本不同细节来决定电源电压，就会导致笔记本不通用，甚至难以充电。

优点：实现模块松耦合；在大的项目效果明显，并行开发更友好。

 

4.接口隔离原则

 类之间的依赖关系应建立在最小的接口上。

简而言之，接口方法尽量少而小，只留需要的，去掉不需要的。只暴露给调用他的类所需要的方法。

场景：客户购车，只关心价格、外观、驾驶性能等特性，如果非让客户去了解每个零部件供应商、工作原理，甚至制造过程，势必会导致客户所识车臃肿、复杂，而且对客户的要求也更高。

优点：提高内聚，减少对外交互；

 

5. 迪米特法则

 类间解耦。

通俗地，一个类对自己依赖的类知道的越少越好。

场景：公立银行或医院就是一个很好的设计，不用关心银行/医院的架构是怎样的，财务报表是怎么表现的，有国家信用支撑，会相信存在银行的钱不会轻易坑自己，去医院看病不会坑害自己。

优点：低耦合，易扩展。

 

6. 开放封闭原则

 通过扩展来解决需求变化，而不是通过修改已有代码。

场景：比如设计了一本书，已经通过出版社出版，后来发现书中内容有误，如果要修改原书内容，就要召回所有书籍，重新印刷，但是这个工作量是巨大的，而且成本非常高。一种更好的方式是，在官网再扩展出一本勘误，这样有疑问的人可以去官网查询。

优点：降低修改成本；