设计模式专题 - 模板方法设计模式

一. 概述&场景分析

1. 设计模式分类

创建型模式：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式

行为模式：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

2.要学模板方法设计模式，首先需要理解工厂模式（工厂模式是为了解耦，将对象创建和使用过程完全分开）：

  工厂模式可以分为简单工厂、工厂方法、抽象工厂，静态工厂模式

          

工厂模式优缺点：

优点：代码结构简单；获取产品的过程更加简单；满足了开闭原则，即对拓展开放，对修改关闭

缺点：拓展较繁琐，要拓展时，需同时改动抽象工厂和工厂实现类

3. 模板方法设计模式

什么是模板方法：

① 定义了一个操作中的算法的骨架，而将部分步骤的实现在子类中完成，模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 

② 模板方法模式是所有模式中最为常见的几个模式之一，是基于继承的代码复用的基本技术，没有关联关系。 因此，在模板方法模式的类结构图中，只有继承关系。

核心设计要点：

AbstractClass : 抽象类，定义并实现一个模板方法。这个模板方法定义了算法的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类去实现

ConcreteClass : 实现实现父类所定义的一个或多个抽象方法

白话文解释：定义一个抽象类，相同的方法自己写（不是抽象方法），不同的写个抽象方法留给子类实现(抽象方法)

场景分析：如下图所示，即聚合支付平台的支付回调代码，多家支付回调通知参数报文都不相同，通知行为(改状态)是相同的

暂定异步回调流程为：

① 解析报文（验证签名）

② 日志收集（相同）

③ 如果解析报文成功的话，修改支付状态为已支付.返回不同的支付结果

此时，可以利用模板方法设计模式重构代码！

二. 代码实现

1. 定义抽象类（共同骨架），其中200响应码是在实现中定义的，这里判断如果不为200，则验签失败，由于支付宝，微信，银联的返回失败的结果都是不一样的，则又定义一个抽象方法resultFail()让子类去实现，同样的也定义成功抽象方法resultSuccess()

2. 定义具体实现（第1步为验签，第3步为解析报文，返回结果，第2步为相同行为，在抽象类封装好了，不需要实现）

① 支付宝回调实现

② 银联回调实现（这里仅做演示，修改订单状态直接用log代替了~）

3. 使用工厂模式获取具体实现模版

附上SpringUtils工具类源码：

4. 测试（分别测试支付宝和银联，则可以看到自定义的成功返回分别为success和ok，后台打印日志也是遵循123步骤，注意，由于直接把支付宝和银联回调实现注入到spring容器，所以传参的时候templateId一定要为类名首字母小写）