模板模式

最近看李建忠老师的设计模式课程，做些笔记。

每个人有自己的学习方法，我更喜欢把每个设计模式当作应用题来做。

所谓的稳定，可以认为是已知项，所谓的变化，可以认为是未知部分。就像小学生的应用题，已知某些条件，求算未知数。

先从模板模式开始。

假如有这样一个项目，已知若干部分的主要功能和流程，求代码如何实现。几乎所有的项目都会这样出题，或者说，这道题满足所有的项目。不过没关系，还需要继续加条件。随着条件的增多，便会指引我们选择到一个合适的设计模式。

继续分析，发现这些模块功能和流程有很多相似处。首先流程几乎一致，都会有A、B、C等步骤，而且流程都是A-B-C。个别模块比较特殊，ABC的具体内容不太一样。也有的模块有一些额外的功能，但不影响ABC和他们的步骤。

开始寻找解题实现方法：

首先，有相同的公共部分，那么公共部分的函数，可以独立开发一套，然后各模块复用即可。流程一致，需要有一个公共的流程调用函数，把各个功能串起来。类似一个调度函数。显然这也是一个公共函数，各个模块复用即可。个别特殊的模块，只需要实现自己特殊的部分即可，不需要把所有功能都实现一遍。流程相关的调度函数，需要做一个调度函数，把各个模块的函数作为参数传给它，让它调度一遍即可。这是我们最朴素的想法，最直接的想法。没有任何实现技巧在里面。只是想着把功能分工实现，避免过多的开发重复代码。

然后，开始寻找实现技巧。注意顺序，一定是先分析业务需求，编写功能实现方案，再寻找实现方法。我认为实现方法是下下策，却被很多人追捧的五颜六色。分析需求，罗列待实现的功能，拆分模块，这个虽然很简单，但并不容易做好。代码方案却是最容易被套路的一个。（这里很难把功能实现方案和代码方案解释清楚。我想表达的意思就是功能描述和划分 与 具体代码实现的问题。）功能描述时应明确的把重复部分，重叠部分描述清楚，提取的公共部分，也就跃然纸上。有了这些公共部分，有了后续可能会发生变更的预期，在具体实现时，就显而易见了。提炼一下，有公共函数，有公共流程。这简单极了，就是好几个同种模块啊。没得说了，一定是一个娘生的。娘一定要提供一些公共函数，每个个体的特异的部分，自己去做，但是流程还是用娘的。公共函数：public继承，特异函数：虚函数与多态。实现这个完全没问题啊。

最后开始写代码。写代码的时候，需要注意：基类的构造函数要用virtual。避免子类new给父类指针时，构造错误。明确好各模块的功能分工，是public就是public，是private就是private。protected就是protected。不要多，也不要少，正正好才是最好。这样，原来的若干个模块，就变成了一个模块和若干个特殊模块的特殊函数。