一文整合工厂模式、模板模式、策略模式

为什么使用设计模式

今天终于有时间系统的整理一下这几个设计模式了， 这几个真是最常用的，用好了它们，你就在也不用一大堆的if else 了。能更好的处理大量的代码冗余问题。

在我们的实际开发中，肯定会有这样的场景：我们的某个方法被多次重复调用，但是每次呢，还需要稍微的改动里面一部分的内容。但是我们常常的写法就是，既然能复用，那我就把原来的接口copy出来一份再改一该里面的内容。（哦，nice，真快，三下五除二解决）但是这样的代码其实就真的只是能运行，给后期运维会带来很大的压力。

倘若我们系统第一版本就这么开发完成了，到第二版需求迭代时。
老板说：“把某某某功能改一下，原来的逻辑统一变了，这个就小改动应该很快吧，给你半天时间。”
然后你说：“我靠，那这工作量太大了， 我每个接口都有这个代码，这一变动，就要全部修改，我点需要两天时间。”
老板说：“这么个破修改你要两天，别再这摸鱼了啊，半天肯定能完事，我自己都能改完， 半天改不完，baibai”
然后你默默翻到我的文章，周末两天连续加班，修改了所有代码，全用上了这套设计模式，以后老板给你估算半天修改时间， 你抢答说：“不用，一两个小时吧就够了”。哈哈哈

设计模式介绍

工厂模式（Factory Pattern）是一种创建型设计模式，用于创建对象的实例化逻辑与客户端代码的分离。在工厂模式中，通过工厂类封装实例化对象的过程，客户端代码不需要直接调用构造函数来实例化对象，而是通过工厂类来创建对象。这样可以提供更灵活性和可维护性，且符合开闭原则。工厂模式常见的几种形式包括简单工厂模式、工厂方法模式和抽象工厂模式。

模板模式（Template Pattern）是一种行为设计模式，用于定义算法的骨架，将可变部分延迟到子类中实现。在模板模式中，定义一个模板方法用于规定算法的流程，同时定义一些抽象方法或钩子方法，子类可以重写这些方法以定义具体实现。通过模板模式，可以避免重复的代码，并提供一个统一的算法框架。

策略模式（Strategy Pattern）是一种行为设计模式，用于定义一系列算法，并将每个算法封装成一个独立的策略对象，客户端可以根据需要在运行时选择算法。在策略模式中，算法之间可以互相替换，独立于客户端，并相互独立运行。策略模式可以提高代码的灵活性和复用性，同时符合开闭原则。

实战代码讲解

常规写法

我们就拿最简单最热门的业务，电商项目的支付功能来讲解。
首先我们创建一个支付的接口。

public interface WxPayService {
    void pay(PayParams payParams);
}

public interface AliPayService {
    void pay(PayParams payParams);
}

随便定义一下这个接口参数

@Data
public class PayParams {
    private String name;
}

然后像我们正常的Javaweb项目一样，创建正常的MVC三层结构。

public class WxPayServiceImpl implements PayService{
    // 实现接口中的方法
    @Override
    public void pay(PayParams payParams) {
        // TODO 第一步：检验一些数据参数是否合格

	// TODO 第二步：微信支付具体步骤

	// TODO 第三步：支付成功，进行一些回写、赋值、返回等等操作。
    }
}

public class AliPayServiceImpl implements PayService{
    // 实现接口中的方法
    @Override
    public void pay(PayParams payParams) {
        // TODO 第一步：检验一些数据参数是否合格

	// TODO 第二步：支付宝支付具体步骤

	// TODO 第三步：支付成功，进行一些回写、赋值、返回等等操作。
    }
}

最后再定义一个controller层，调用

@Autowired
private WxPayService wxPayService;

@Autowired
private AliPayService aliPayService;

@PostMapping(value = "/WxPay")
public ResponseResult pay(@RequestBody PayParams params) {
    wxPayService.pay(params);
    return ResponseResult.success();
}

@PostMapping(value = "/AliPay")
public ResponseResult pay(@RequestBody PayParams params) {
    aliPayService.pay(params);
    return ResponseResult.success();
}

这样是实现了我们的支付功能，一个微信支付，一个支付宝支付。但是我们会发现，这样写出来的代码，冗余非常多。

接下来我把这个业务代码修改为使用设计模式的格式。

设计模式后的代码

首先我们还是创建一个支付接口。

public interface PayService {
    void pay(PayParams payParams);
}

然后我们来，实现这个接口，因为我们目前就有两种支付方式，等项目后续升级肯定还会接入越来越多的支付方式，所以我们这里目前就要有两个实现类来实现这个接口， 以后可能更多。

观看上图我们有发现，在实际的业务逻辑中，其实每个支付的代码中的第一步和第三步都是一样的，所以我们可以把它抽离成一个模板。模板模式这就被使用了。代码如下：

public abstract class PayServiceAbstract implements PayService{
    // 实现接口中的方法
    @Override
    public void pay(PayParams payParams) {
        before(payParams);
        realPay(payParams);
        after(payParams);
    }

    // 把这个核心支付功能定义为抽象的方法,留给具体的策略实现类去实现。
    public abstract void realPay(PayParams payParams);

    // 支付之前、之后的操作在抽象类中就定义一个模板方法，
    // 只要掉用了这个抽象方法就自己有该模板可使用。
    public void before(PayParams payParams){
        System.out.println("支付前操作");
    }
    public void after(PayParams payParams){
        System.out.println("支付后操作");
    }
}

上面代码中，我们是用一个抽象类实现了接口，但是抽象还不是具体的实现，它只是固定了一个模板，接下来我们就要有每个支付方式自己的类去做具体的实现，这个也就是策略模式。对一个接口分别使用不同的策略来做不同的事。

支付宝支付的具体策略服务

@Service
public class AliPayServiceAbstractImpl extends PayServiceAbstract{
    @Override
    public void realPay(PayParams payParams) {
        System.out.println("支付宝支付处理中。。。。");
    }
}

微信支付的具体策略服务

@Service
public class WxPayServiceAbstractImpl extends PayServiceAbstract{
    @Override
    public void realPay(PayParams payParams) {
        System.out.println("微信支付处理中。。。。");
    }
}

ok，到目前，策略模式 + 模板模式就使用成功了，每当需求再叠加时，我们只需要再加一个具体的策略服务就ok了。别的地方都不需要动。

接下来时控制层的调用。我们如果还是用原来的controller，定义一个微信支付接口一个支付宝支付接口，那也太麻烦了。而且如果以后再有个银行卡支付，apple支付，那每次还要新增接口，真麻烦。所以我们不妨使用工厂模式来解决这个问题，让工厂来帮我们确定到底要用哪种支付。这样就来到了我们的工厂模式。

定义一个工厂

@Service
public class PayFactory {
	// payType 哪个具体策略服务
    public PayServiceAbstract getFactory(String payType){
        try {
            Class<?> aClass = Class.forName("com.bihe.controller."+payType);
            PayServiceAbstract payServiceAbstract = (PayServiceAbstract) aClass.getDeclaredConstructor().newInstance();
            return payServiceAbstract;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

上面的代码中，我们是用了Java反射，根据我们传递进来的类名，自动反射创建出具体的策略对象。

最后就是我们的控制层了。

@PostMapping(value = "/pay")
    public ResponseResult pay(@RequestBody PayParams params) {
        PayServiceAbstract payServiceAbstract = payFactory.getFactory(params.getName());
        payServiceAbstract.pay(params);
        return ResponseResult.success();
    }

这就非常简单了， 我们永远只用这一样接口，前端也不需要判断我什么时候调用weixin支付，什么时候调用ali支付…
前端可以一直调用这个一个接口就可以了，只是把响应支付的关键参数传递过来就可以了。

前端调用

🆗啦，这样的代码是不是非常的规整，我们后续如果再添加一个新的支付接口就只需要再加一个具体的策略实现类就可以了，如果老板还要修改以前的统一的业务逻辑，那我们也是只需要在模板中也就是抽象类那层修改就可以啦。

哇，代码终于干净了，整个人都舒服了。哈哈😊

查看原文章可进入我的个人博客： 沉思随笔 。欢迎大家🤞