1 前言
在日常的开发过程中，经常会遇到一些复杂的业务场景，那么如何优雅的实现复杂的业务功能，而且使得系统的性能、可靠性、可读性达到最好呢？这里不仅考验着开发者的编程功底，实践能力，还有对局部和全局的把握能力。我们都知道，java 是面向对象编程的语言而非面向过程编程的语言，但是在实际操作中，常常会为了走捷径实现功能，忽略了代码的结构性建设，久而久之项目就是堆砌成屎山，系统性能降低，可读性差，系统的可维护性降低，扩展难度极大。为了解决这样的问题，就需要开发者修炼自己的设计功底，学好并用好设计模式。在本文要谈的就是对策略和模板设计模式使用心得与体会。
2 应用场景
之所以会将策略和模板模式放在一起，是因为这两种模式用的最多最广泛，而且基本都是联合使用的。在开始之前，先复习一下模式的定义：
- 模板模式(
Template Pattern)
模板模式是在一个抽象类中定义执行的方法，每个方法中都有一个对应的业务流程模板，它的子类需要按照需要来重写模板流程中的方法，调用方法将以抽象类中的方式进行，这种设计模式也属于行为型模式。
- 策略模式(
Strategy Pattern)
策略模式是指一个类的行为或者方法，可以在运行时根据条件进行修改，策略模式也是一种行为性模式。在使用策略模式时，通常会创建一个策略上下文 Context ,根据不同的情况选择不同的策略。
不管是策略模式还是模板模式，都是运用了 java 多态这一特点，父类引用指向之类对象，通常情况下，模板模式使用的是抽象类，而策略模式使用的是接口而已。其子类都需要子类重写其父类方法或者实现接口方法，两者都满足开闭原则，使得系统在不影响其它功能的前提下更容易扩展。但是两者又有一些差异，模板模式是一种耦合的模式，策略模式是一种松散的模式。模板模式中，通常只有一个业务方法的入口，策略模式中的接口通常会有多个。
单纯的策略模式和模板模式在实践中应用很少，一般都是两种模式结合起来使用，如下图所示，这里即使用了模板模式的高内聚的业务流程，也使用了策略模式的松散性，相同的内容放在抽象类中进行处理，特有的内容放在具体的实现类里面进行操作。
3 应用实践
在介绍了其应用场景后，在这里将结合实际的业务场景来介绍两种设计模式的合并使用。这里采用的是下单支付的场景，用户下单支付完成后，需要邮件和短信通知用户，并且给用户发积分并发送 MQ。
首先，我们需要定义一个接口类，如下图所示，定义了业务流程方法，发送邮件以及发送短信等方法。 
实现接口的模板抽象类，定义了业务的流程顺序，以及抽象的支付方法。同时也实现了实现了发送短信和邮件的方法，还有一个发送消息的方法。 
阿里业务类型实现类，这里实现了支付的方法，以及发送短信和邮件的方法，这里不同的业务可能配置不同的短信发送服务，通用的短信发送在抽象模板进行处理，特有的可以在具体的实现类里面实现。 
其它两个微信和网银的实现类就不在这里展示了，和阿里的业务类似，具体的可以参见项目代码。
通过以上的操作，我们已经实现了业务骨架编码，但是该怎么调用呢？这里提供了两种方法，一是使用 spring 注入的方式，另外是使用枚举，通过 ApplicationContext 获取对应的 bean。
通过 @Autowired 来注入 private Map<String, BaseBusiness> businessMap;, 这里需要具体的实现类名称不能有重复，第一种就是通过接口传入的 payType 通过判断来获取对应的 BaseBusiness。第一种方式需要写多个 if 判断条件，显然不是很优雅。
在介绍第二种方式之前，先来看一个枚举类，这个枚举类比较特殊，定义了支付类型，Bean 名称和业务描述以及对应的 Bean Class。这里定义了一个 matchBusiness 方法，在该方法中使用 SpringUtils 工具类从 Spring 上下文获取对应的 Bean, 这里使用的是 Class 来获取 Bean, 当然也可以使用 Bean 名称来获取 Bean。
通过以上方式，我们就可以很方便的使用模板和策略模式的结合体，能够很方便的实现业务功能。
4 总结
在本文中，使用了一个案例来分享作者对策略模式和模板模式理解和应用，综合使用两种模式的优点，两者的结合避免了一些不足。在使用时，没有使用常用的上下文对象来获取对应的业务处理器，而是使用了一个枚举类来实现，这样通过该枚举类就可以从宏观来了解所有的策略，并且减少了一些判断的代码，使得代码简练，结构清晰。本文中所涉及的代码，已经上传至 github, 欢迎大家点赞和 stars。项目 github 地址 springboot-auth。