题外话
回想起大学学过一门课程《设计模式》，里面描述了很多包含前人思想精华的设计模式，用于构建代码。工作久了，虽然在写嵌入式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; }
功能上，这个做法没有问题。但是，一旦项目的复杂度高，或者参与的人数多了，会让别人、甚至自己都看不懂，造成很大的困扰；如果应用层代码一旦有修改，比如换个变量名字，添加一个定时器，都需要修改底层。显然，这是不合理的。比较合理的做法是，底层应该是调用硬件驱动，给上层以接口形式提供服务，而不是强迫底层必须了解上层的细节，修改上层时也必须修改底层。
试想，如果操作系统不得不关注应用程序具体是如何使用某项功能的，而且应用的功能修改，操作系统底层必须修改，这种设计后果有多可怕。而处理这个问题有一个很不错的思路：就是将应用的定时器功能委托给底层硬件定时器模块，而底层只提供接口，不关注应用的使用细节。
没有经过封装的用法：
经过委托模式思想封装的用法：
参考
2. 设计模式六大原则
设计模式
总原则： 低耦合，高内聚；对扩展开放，对修改关闭。
六大原则
1. 单一职责原则
应该有且只有一个原因引起类的变化。简单来说，一个类负责一项职责，功能要单一。
场景：比如一个程序员既要负责编码，又要负责测试，那么编码出现问题的时候，就容易影响到测试；测试出问题的时候，就容易影响到编码。如果程序员只负责一项工作，那么就会，
优点：提高可扩展性、可维护性，降低类的复杂度。
2. 里氏替换原则
只要父类出现的地方，一定可以使用子类，而且不会出现任何异常。这样，使用者不需要知道是父类还是子类。
场景：商场为客户（人）提高购物场所，任何人都可以进去购物。如果非要针对每个人的职业、年龄、身体状况进行区分判断、对待，那么这个工作量无疑是巨大的。而且是不安全的，因为商场不得不针对实际情况修改验证规则。
优点：程序健壮性增强；即使增加不同子类，不影响原类运行。
3. 依赖倒置原则
高层模块不依赖底层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
简而言之，对接口编程，而不是对实现编程。
场景：笔记本电脑虽然每个型号的充电插座端接口不一定相同，有TYPE-C的，有圆孔的，还有方口的，不过都会根据220V电源提供充电插头（接口），否则设计比较的时候按每个笔记本不同细节来决定电源电压，就会导致笔记本不通用，甚至难以充电。
优点：实现模块松耦合；在大的项目效果明显，并行开发更友好。
4.接口隔离原则
类之间的依赖关系应建立在最小的接口上。
简而言之，接口方法尽量少而小，只留需要的，去掉不需要的。只暴露给调用他的类所需要的方法。
场景：客户购车，只关心价格、外观、驾驶性能等特性，如果非让客户去了解每个零部件供应商、工作原理，甚至制造过程，势必会导致客户所识车臃肿、复杂，而且对客户的要求也更高。
优点：提高内聚，减少对外交互；
5. 迪米特法则
类间解耦。
通俗地，一个类对自己依赖的类知道的越少越好。
场景：公立银行或医院就是一个很好的设计，不用关心银行/医院的架构是怎样的，财务报表是怎么表现的，有国家信用支撑，会相信存在银行的钱不会轻易坑自己，去医院看病不会坑害自己。
优点：低耦合，易扩展。
6. 开放封闭原则
通过扩展来解决需求变化，而不是通过修改已有代码。
场景：比如设计了一本书，已经通过出版社出版，后来发现书中内容有误，如果要修改原书内容，就要召回所有书籍，重新印刷，但是这个工作量是巨大的，而且成本非常高。一种更好的方式是，在官网再扩展出一本勘误，这样有疑问的人可以去官网查询。
优点：降低修改成本；