本文系转载，著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作者： 宋宝华
来源： 微信公众号linux阅码场(id: linuxdev)
前言
《设计模式》这本经典的书里面定义了20多种设计模式，虽然都是面向对象的，似乎需要C++、Java这样的语言才能实现，但是根据笔者前面反复强调的，Linux内核虽然是用C语言和汇编语言写成，但是其实也到处充满了面向对象的设计。面向对象更多的是一种思想，而不是一个语言。我们可以用C语言实现极大的OO，Linux内核到处都有OO。
模版方法
比如，在Linux的设备驱动框架中，就用了一种非常经典简单的设计模式——模板方法(Template Method)，当然还有一些其他的设计模式。而设计模式牛逼的地方在于，高手往往不经意之间已经用到了设计模式，甚至自己都不知道。如果高手没有系统地学习过设计模式，这其实不见得是一个问题。这并不意味着它不懂设计模式，只是他自己都不知道自己用到了哪个模式。而设计模式学习的终极目的，当然也是忘记设计模式，这个跟练独孤九剑没什么区别，到最后其实是无招胜有招。
模板方法这个模式，强调定义一个基类，这个基类实现了通用的流程和算法。比如做一件事情需要经过step1()、step2()、step3()。那么我们定义一个基类：
而其中的step1()、step2()、step3()、step4()具体如何实现则是因人而异，所以我们从baseClass类里面，继承出来的类里面，实现step1()、step2()、step3()这样的代码，override掉baseClass里面的函数。
这样的设计让外部不关心derivedClass，因为流程和接口都是在基类的。而基类实现的doSomething()成员函数，是对外的接口。这个UML关系是非常简单的：
驱动案例
在Linux设备驱动里面，大量存在类似的设计，我们以NAND为例子。在drivers/mtd/nand/nand_base.c这层里面，定义了NAND的一些操作流程。
比如写OOB的代码：
它这个里面要走cmdfunc()、write_buf()、cmdfunc()、waitfunc()这些步骤，这些步骤，不管是全世界哪个NAND的硬件，都是一样的通用的，但是具体的不同的NAND硬件控制器，实现这些步骤中涉及到的cmdfunc()等函数的实现方法却因人而异。
譬如freescale的版本fsl_elbc_nand.c就是：
nand_base.c这个C文件是NAND的中间层，它非常类似我们前面说的实现baseClass这一层的代码，nand_write_oob_std函数类似baseClass :: doSomething。而Linux驱动中定义的nand_chip的各个不同的NAND控制器，对nand_chip这个结构体中成员函数cmdfunc()、write_buf()等的实现则是各异的，类似derivedClass里面override掉step1()、step2()。nand_chip定义在include/linux/mtd/nand.h：
这样的设计，好处是非常明显的。特定的硬件只用管与自身操作相关的事情，而通用的流程，都由nand_base搞定，最大程度上减小了具体实例的代码量，也最大程度上复用了中间层的代码。
这样的例子无处不在，比如我们在LCD的中间层：
后语
本文后语不搭前言，请见谅。最近有很多童鞋询问笔者，做Linux驱动有没有前途？笔者明确地告诉大家：根本没有前途！但是前途是自己赚的，这依赖你从驱动进去，但是从更大的视角出来：
通过做驱动理解很多OO的架构设计思想，升华自己高内聚和低耦合的理解，把自己变成一个更高level的software engineer；
通过做驱动，进一步理解Linux本身的进程、内存、IO等知识，升华对软件系统和性能分析的理解，把自己变成一个更高level的技术expert。
如果做了5年驱动，进入的时候是调试寄存器搞示波器，出来的时候还是调寄存器搞示波器，那自然是完全没有什么前途的！
有没有前途，这个事情，完全是因人而异的。前途是无所谓有，无所谓无的。你如果有抽象、衍生的能力和不断学习总结的精神，无论是做驱动还是不做驱动，都会是很有前途的事情。反之，做什么基本都没前途。
更多精彩更新中……欢迎关注微信公众号：linux阅码场(id: linuxdev)
