模板化套用

何为模板化，举个例子：

我们的高考作文，虽然学子们文风乱舞，但是别具一格的往往只有几个人。我们绝大部分人即使读明白了题目，大多也是将题目套进被规则化的

**「议论文」**模板中。

这个过程就是 「读题 - 确认业务」， 「确认业务模板」

然后往模板里面填充内容，即「业务内容」

那么提到模板化这一概念，首先当然离不开设计模式中的模板模式

简单的做一个模板模式的介绍：

模板模式介绍

取自菜鸟教程

意图 ：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

主要解决 ：一些方法通用，却在每一个子类都重新写了这一方法。

何时使用 ：有一些通用的方法。

如何解决 ：将这些通用算法抽象出来。

关键代码 ：在抽象类实现，其他步骤在子类实现。

应用实例 ： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。

优点 ： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。

缺点 ：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

使用场景 ： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。

注意事项 ：为防止恶意操作，一般模板方法都加上 final 关键词。

总结来说，即是将一套动作抽象模板化，那么被这套模板套用的业务，一定会执行抽象出的动作

模板思路

模板模式作为八大设计模式之一，模板思路是不可或缺的思考方向。

我们使用某个工具，比如word、画图软件...，在内容描述前，肯定都希望有一份适合自己的模板，这是需求。

软件提前将用户目标值罗列出来，根据分类制造成目标值偏向的主体内容，这是制造模板。

挑选适合自己的模板，然后填充内容，这是使用模板。

模板化设计的思路很简单，即是：

1. 了解需求
2. 罗列目标值
3. 抽象模板
4. 挑选模板
5. 具体化模板
6. 建立成体值

下面将以两个模板化套用的案例仔细介绍

消息-模板化

玩游戏时，会不会发现这样的消息

• XXX发现了XXX
• XXX打开了XXX
• XXX强化XX成功
• XXX邀请你加入
• ....

等等这样由 {} 打开了/发现了/... {} 组合的消息，简单的可以看出这样就完成了我们的第一步**：了解需求**。

需求是什么，用户需要收到这样组合的消息。那么接下来我们需要将他们罗列出来并且分类：

• 个人信息
• 组队信息
• 系统公告
• 家族信息
• ...

将用户需要收到的组合消息放至到罗列出来的对应分组中，这样就完成了第二步**：罗列需求**

接下来就是抽象出消息模板，作为一条游戏内的消息，他一定是这样触发的：

1. 某某某触发了某某动作
2. 查询这个动作影响的人员
3. 然后判断出你应该收到 {}对你造成了{}的动作的消息
4. 判断这样的消息需不需要增强/过滤/...
5. 将最终消息结果集给你

那么这一整个动作就是我们可以抽出来的消息模板，使用伪代码表示：

    public void message(T t) {
        //1、拿到消息模板
        MessageModelDO messageModelDO = messageModelDao.selectById(t.getMessageModel().getId());
        //2、填充消息模型 具体消息 具体标题 图标..
        
        //3、拿到收到消息的用户标识
        userIds = ...;

        //4、增强\过滤\替换..消息
        
        //5、发送消息
        
        //6、推送\短讯服务\...消息后置处理
    }

这样就完成了第三步**：抽象模板**

而第四步 挑选模板，则是业务方触发者根据本身属性挑选对应消息的模板标识

第五步，具体化模板。在本例消息案例中，模板中需要具体化的只有两个，一是标题，二是内容。

可以发现 {} 打开了/发现了/... {} 这样的消息体本身就是填充形式，那么我们也只需要触发者提供其对应的 {} 填充内容，后续抽象模板中使用 检测 {} 符号的方式，就可以简单的完成替换填充的动作。

最终填充完成，就组成了第六步 建立成体值 。

SQL-模板化

上述描述，不知大伙可否脑内形成一个以模板化套用思路驱动的功能架构。

在有开发的项目中，也有一个根据模板化套用思路完成的功能**：根据两张表的对比结果，结果中包括字段名，差异偏移量...根据这些生成以某张表为主表的SQL语句。**

在本质上来说，和消息-模板化思路异曲同工，不过严格的来说；所有模板化套用的思路都比较接近。

下面介绍这个功能的实现思路：

• 第一步，了解需求：以某张表为主表的SQL

• 第二步，罗列需求：根据差异偏移量，生成的SQL可能是，新增字段、删除字段、修改字段、增强字段...

• 第三步，抽象模板：

  1、 根据主表+偏移量 判断模板等级，即是否生成SQL，SQL类型

  2、 挑选对应模板，生成SQL，SQL为新增/删除

  3、 处理模板内嵌套模板，因为一个SQL语句不像 消息-模板化 一样固化。会根据字段是否自增、是否为主键、是否有索引等等，生成一个由某一模板为主体引导的另一套模板值

  4、填充内容，同样的可使用 {} 符号的方式填充字段的名字、类型等等

  5、执行SQL处理策略，由于SQL在各方的需求不同，比如类型datetime(26)为MySQL默认值，但是SQL语句不支持，需要进行类型转化为datetime(0)；某个SQL需要与表属性连体变动，进行SQL的增强等等

  6、...

相关项目可见：DbShop

总结

强调一下这个不起眼但确实一种基本素养的思路，因为生活中常常存在模板化套用的东西，比如导航推荐线路、衣柜中的存放格、厨房用品放置架等等等等。

希望大家可以将这种不起眼，但引用在代码设计中却意外好用的思路在平时开发中可以套用起来。