前言
从一个普通的码农成为架构师的第一步,就是要从代码搬运转化为有自己一套设计方法。架构设计的基石,就是要拥有一套可信手拈来的设计模式。
在之前一直认为C语言在这一块的设计思想特别稀缺,而事实也是如此。但其实想想编程语言的一个发展过程会发现,不是C语言没有人总结好的设计方法,而是大部分方法在更高级的语言里(如C++、Java)里已经被人总结了无数次。今天就来讲讲面向对象语言里的一个传世经典——设计模式。
一开始其实是被这本书名劝退的。书全名《设计模式——可利用面向对象软件的基础》。众所周知,C语言是面向过程的语言,C++、Java这种才是面向对象的语言。而且书中开篇就直接表明,书中所有设计模式跟例子,都只针对于面向对象语言,不在面向过程类的语言上做讨论。但这里我们需要有一个意识,就是面向对象或面向过程,更多指的是一种思维方式,不是说C语言就不能做一些面向对象的设计,而不是特指C语言。网上也有很多C语言面向对象的优秀例子,比如伟大的Linux内核不就是C语言开发的吗。另一本经典著作《Java编程思想》,正文也是跟Java这个编程语言搭不上边,更多讲的是一种思想。
在编程语言发展迅速的今天,C语言仍然能够占有一席之地,离不开其灵活性和可塑造性。所以我们应该打开思路,大胆参考借鉴其他语言的一些设计思路,有助于身为“C语言大佬”的我们,真正成为一个大佬。
前置能力
既然设计模式是码农到架构师的进阶之路,那么前提就是你已经成为一名合格的码农。那到什么程度才适合学习设计模式呢?首先需要满足以下两点:
1. 需求理解能力
需求是设计的灯塔,只有对需求有正确的理解,才能对其进行设计。注意哦,这里只是说需求理解,不是需求管理。因为对于需求管理,里面包含着太多太多的学问。但是对于需求的理解,则是一名程序员入门必备的技能。如果需求都无法正确理解,无法做拆分,那做出来的东西必定是偏离初衷的。就像是在建房子,无论你的设计能力有多强,设计的房子有多漂亮,但别人要求价钱建个医院,你却建成了酒店,甚至在这个地方是个违建的建筑,这让别人怎么使用。
2. 需求实现能力
充分理解了需求后,那就需要对需求进行转换,从人类可以理解的语言逻辑,转换成符合代码规则的逻辑。因为这里跟代码挂钩,所以针对不同的语言特性,这里会有不一样的转换思路。为什么这个能力很重要,那是因为本文所讲的设计模式,其实是优化需求实现的过程,如果没有一个原始的实现版本,怎么来谈优化?如果连需求怎么实现都不清楚就来讲设计,那无疑是在纸上谈兵。
其实上面提到的两个点,分别对应软件工程里的需求收集管理和详细设计,而接下来我们要讲述的设计模式,则是属于详细设计的内容,对详细设计的优化。对于软件工程的相关知识,这里就不展开讲了,后续有时间的话我们可以专门针对这个聊一聊。(你们很关心的架构设计,是属于概要设计的内容哦)
对于需求的实现,这里先提供一种基础的设计方式,也是本人最喜欢的设计分析模型——数据流。把需求的输入到实现,拆解成“输入”、“解析”、“输出”三部分,再将其中每一部分进行拆解,一直拆解到无法再往下拆分的程度,这时候就可以得到一条数据流路。
比如现在要求做一个自动浇水的机器,那么拆解的第一步,输入是土壤干,输出是浇水,中间是控制器。然后再具体一下,土壤是否干,需要有个检测土壤湿度的传感器,浇水则是需要有个可以控制出水的装置。于是输入部分可以拆解成,输入是土壤干,输出是土壤干的信号,中间是传感器。输入部分可以拆解成,输入是控制出水的信号,输出是浇水,中间是出水装置。以此类推,到最后,如果只要做中间控制器的部分,那只要实现中间这条数据链路即可。
然后有了数据流向分析的能力后,怎么跟后面要提到的设计模式扯上关系呢?这里稍等总结了一下,所有的设计模式,都要基于一个大前提,那就是对数据和逻辑的抽象归纳。以下所有设计模式都是基于抽象共性得到。根据抽象内容的不同区分出这些设计模式。因为是基于抽象共性的基础上进行的设计模式,所以设计模式只适用于设计的对象必须是存在不变部分的情况。如果设计的对象全是变化部分,那就没有设计模式什么事了。
目录链接
讲了这么多,那么接下来就来看下设计模式都有哪一些。这里根据共性对象的不同,区分了创建型、结构型和行为型,这也是书中区分的三大章节。而最后一个表驱动,则是基于C语言的设计特性出来的一个方法,不在设计模式书中提及,而是在另一本著作《代码大全》中提及。
创建型
抽象工厂
生成器
工厂方法
原型
单件
结构型
适配器
桥接
组合
装饰
外观
享元
代理
行为型
职责链
命令
解析器
迭代器
中介者
备忘录
状态模式
策略
模板方法
访问者
表驱动
相关知识
设计模式、软件工程