最近看李建忠老师的设计模式课程,做些笔记。
每个人有自己的学习方法,我更喜欢把每个设计模式当作应用题来做。
所谓的稳定,可以认为是已知项,所谓的变化,可以认为是未知部分。就像小学生的应用题,已知某些条件,求算未知数。
先从模板模式开始。
假如有这样一个项目,已知若干部分的主要功能和流程,求代码如何实现。几乎所有的项目都会这样出题,或者说,这道题满足所有的项目。不过没关系,还需要继续加条件。随着条件的增多,便会指引我们选择到一个合适的设计模式。
继续分析,发现这些模块功能和流程有很多相似处。首先流程几乎一致,都会有A、B、C等步骤,而且流程都是A-B-C。个别模块比较特殊,ABC的具体内容不太一样。也有的模块有一些额外的功能,但不影响ABC和他们的步骤。
开始寻找解题实现方法:
首先,有相同的公共部分,那么公共部分的函数,可以独立开发一套,然后各模块复用即可。流程一致,需要有一个公共的流程调用函数,把各个功能串起来。类似一个调度函数。显然这也是一个公共函数,各个模块复用即可。个别特殊的模块,只需要实现自己特殊的部分即可,不需要把所有功能都实现一遍。流程相关的调度函数,需要做一个调度函数,把各个模块的函数作为参数传给它,让它调度一遍即可。这是我们最朴素的想法,最直接的想法。没有任何实现技巧在里面。只是想着把功能分工实现,避免过多的开发重复代码。
然后,开始寻找实现技巧。注意顺序,一定是先分析业务需求,编写功能实现方案,再寻找实现方法。我认为实现方法是下下策,却被很多人追捧的五颜六色。分析需求,罗列待实现的功能,拆分模块,这个虽然很简单,但并不容易做好。代码方案却是最容易被套路的一个。(这里很难把功能实现方案和代码方案解释清楚。我想表达的意思就是功能描述和划分 与 具体代码实现的问题。)功能描述时应明确的把重复部分,重叠部分描述清楚,提取的公共部分,也就跃然纸上。有了这些公共部分,有了后续可能会发生变更的预期,在具体实现时,就显而易见了。提炼一下,有公共函数,有公共流程。这简单极了,就是好几个同种模块啊。没得说了,一定是一个娘生的。娘一定要提供一些公共函数,每个个体的特异的部分,自己去做,但是流程还是用娘的。公共函数:public继承,特异函数:虚函数与多态。实现这个完全没问题啊。
最后开始写代码。写代码的时候,需要注意:基类的构造函数要用virtual。避免子类new给父类指针时,构造错误。明确好各模块的功能分工,是public就是public,是private就是private。protected就是protected。不要多,也不要少,正正好才是最好。这样,原来的若干个模块,就变成了一个模块和若干个特殊模块的特殊函数。