已经很久没更新了，在这期间经历了准备面试、面试、离职又入职的过程，目前已经入职接近2个月，虽说从离职到入职只间隔了4天还包括一个周末。但入职后新工作这段时间还是给我带来了不一样的感悟，抽空我会单独“水”一篇文章说说从传统行业到互联网行业带给我的感受。
好了言归正传，我们今天讨论的跟设计模式有关。从标题大家应该已经知道是哪两种模式。这两种模式在Spring中都广泛存在，例如大家所熟知的Spring Data模块，存在JDBCTemplate、RedisTemplate、MongoTemplate等均是典型的模板模式。又例如Spring MVC中各种处理handler，是典型的策略模式。
遇到的场景
然而，能举例说明是一回事，在自己的代码中灵活运用是另外一回事。我最近在开发的过程中遇到需要对不同if进行不同处理的场景。伪代码如下
PushVO pushVO = null;
if(OrderStatus.WAIT_COMFIRM == orderStatus){
// do something
pushVO = xxx;
} else if (){
// do something
pushVO = xxx;
} else if ...
redisTemplate.opsForList().leftPush(pushVO);
xxx
这种代码应该在工作中很常见，简单粗暴，后期维护起来也比较简单，有新人来也能很快明白处理方式不同。但最近看别人的代码，深刻意识到设计模式的优点，代码简洁，符合开闭原则，可读性更高，因此自己也想尝试用更“高端”的方法来实现这段逻辑。
引发的思考
最开始的时候自然而然就想起了策略模式来优化代码设计。通过分析发现，不同策略中又有大量的冗余代码，例如调用公共接口，执行通用逻辑及最后存入Redis。随机又感觉此处适合模板模式，因此产生了思考，到底策略模式和模板模式有什么区别？他们是不是可以相互替换？他们各有什么优缺点？究竟什么时候该用策略模式什么时候该用模板模式？为什么Spring在运用中可以做到清楚的区分运用场景？
解惑的过程
带着疑问在网上搜索已一番，发现原来不是我一个人有这种疑问，很多人都有这个疑问。经过几番查找终于有了更清晰的理解。我们先来看看这两种模式的表现形式。
策略模式和模板模式的表现形式
首先我们来看模板模式
通常来说模板模式都是由抽象类来定义一个算法，在算法实现的不同步骤上抽象方法由子类继承并提供具体实现，常见的就是不同步骤提供doXXX抽象方法留给子类实现。模板模式一般有两部分组成，即抽象模板和具体模板。
策略模式
策略模式则是以接口形式提供抽象接口。由具体实现类提供不同算法。策略模式一般由3部分组成
- 一个Context持有所有策略实现类引用，提供给客户端运行
- 一个策略接口提供
- 具体的策略实现类
通过上面可以看到，策略模式和模板模式有一个最重要的区别，即模板模式一般只针对一套算法，注重对同一个算法的不同细节进行抽象提供不同的实现。而策略模式注重多套算法多套实现，在算法中间不应该有交集，因此算法和算法只间一般不会有冗余代码！因为不同算法只间的实现一般不同很相近。
因此我们可以看到，策略模式的关注点更广，模板模式的关注点更深。而且两种模式可以一起使用，即具体某个策略下可以通过模板减少不同步骤的冗余代码。
举个简单例子，有一个玩游戏的策略类，提供一个playGame的方法，一般而言游戏可以分为Moba类、FPS类、模拟经营类、棋牌类等等，这些不同类型的游戏可以看作是不同策略，因为他们玩法大不相同。然而针对同一类型下的游戏，又可以在PC、XBox、手机甚至VR体感设备等玩耍。此时可以提供抽象类提供通用的操作方法，使用抽象方法来引导子类实现。例如Moba类游戏，不管在那个平台上都会有选人，开始游戏。而FPS类则基本打开游戏就可以直接玩。因此可以针对不同类型游戏提供统一的父类来减少冗余代码。
得到的结论
现在我们可以回答开始提出的几个问题了。
策略模式和模板模式有什么区别
上面我们已经说了，策略模式关注多种算法，模板模式关注一种算法。策略模式不同策略只间代码很少冗余。
他们是不是可以相互替换
从上一小节我们已经知道他们之间不能替换，但可以组合使用。
他们各有什么优缺点
| 模式 | 优点 | 缺点 |
|---|---|---|
| 策略 | 横向扩展性好，灵活性高 | 客户端需要知道全部策略，若策略过多会导致复杂度升高 |
| 模板 | 可维护性好，纵向扩展性好 | 耦合性较高，子类无法影响父类公用模块代码 |
究竟什么时候该用策略模式什么时候该用模板模式
针对具体需求具体分析，没有最好的模式只有最合适的模式。只要了解了他们只间的区别及优缺点。选择最合适的方法即可。
