全栈之路-杂篇-探究SpringBoot多例模式注入的方案

  毫无疑问的，springboot托管的实体类默认是以单例模式的形式进行实例化的，但是在某些场景下，我们需要的不是单例模式的实体类，这个时候我们该如何去实现springboot托管的实体类进行多例模式的创建呢？

一、单例模式存在的问题

1、业务场景介绍

  就是我们为什么会有改变springboot默认单例模式的这种创建bean的形式？这个业务场景是这样的，我们在做优惠券的校验的时候，我们自己封装了一个优惠券的校验类，这样的话，我们就可以很方便的进行统一的优惠券的校验了，在做优惠券的校验的时候，我们会有一个打折的情况，这里会出现一个四舍五入的问题，就会导致数据并不是原来的数据，会有一个偏差，我们到底是采用什么模式进行小数的取舍，这里是值得探讨的，但是我们这里的处理方式是将折扣价的计算封装成了一个接口，这样我们写了几个实现类，有四舍五入的方式，有直接舍去的方式，有银行家算法的方式，我们在使用的时候直接使用实现类来计算就好，在代码中我们是这样实现的：

接口类：

// 接口类
public interface IMoneyDiscount {
    BigDecimal discount(BigDecimal original, BigDecimal discount);
}

第一个实现类（四舍五入）：

public class HalfUpRound implements IMoneyDiscount{

    @Override
    public BigDecimal discount(BigDecimal original, BigDecimal discount) {
        BigDecimal actualMoney = original.multiply(discount);
        BigDecimal finalMoney = actualMoney.setScale(2, RoundingMode.HALF_UP);
        return finalMoney;
    }
}

第二个实现类（向上取整）：

public class UpRound implements IMoneyDiscount{
    @Override
    public BigDecimal discount(BigDecimal original, BigDecimal discount) {
        BigDecimal actualMoney = original.multiply(discount);
        BigDecimal finalMoney = actualMoney.setScale(2, RoundingMode.UP);
        return finalMoney;
    }
}

第三个实现类（银行家算法）：

public class HalfEvenRound implements IMoneyDiscount{
    @Override
    public BigDecimal discount(BigDecimal original, BigDecimal discount) {
        BigDecimal actualMoney = original.multiply(discount);
        BigDecimal finalMoney = actualMoney.setScale(2, RoundingMode.HALF_EVEN);
        return finalMoney;
    }
}

我们在做订单校验的时候，需要对优惠券进行校验，在做优惠券校验的时候，我们构建了一个CouponChecker的优惠券校验类，在这个类中我们会做订单金额的校验，当然可以直接使用new对象的方法，来使用折扣计算的方法，但是我们这里使用的是注入的方式来优化这个，但是这样就存在问题了，我们需要的是每一个订单都是有每一个校验的，这时候单例模式就存在问题了，因为我们是需要Coupon类和UserCoupon类同时作为参数传入进行CouponChecker类中的，也就是我们通过传统的new对象的方式进行校验，但是如果是单例模式的话，这些是没有办法使用的。

2、单例模式下的实体类不能有自己私有的成员变量的，即使有的话，那么这些成员变量也必须是单例模式的，所以我们必须解决这个单例模式的问题，来符合我们业务的需要

二、解决方案

1、我们把CouponChecker作为一个不在springboot容器中托管的类，只是作为一个普通类来操作，这样我们在service层，也就是OrderService类中将IMoneyDiscount的实现类作为参数传入到CouponChecker中，这样可以解决那个单例模式存在的问题，代码如下：

（1）OrderService类，来处理order订单相关的逻辑类：

@Service
public class OrderService {
    // 省略部分代码......

    @Autowired
    private IMoneyDiscount iMoneyDiscount;

    /**
     * 订单校验的主方法
     *
     * @param uid      用户id
     * @param orderDTO 订单相关数据
     */
    public void isOk(Long uid, OrderDTO orderDTO) {
        // 省略部分代码......
        // 数据的校验
        CouponChecker couponChecker = new CouponChecker(coupon, userCoupon, this.iMoneyDiscount);

    }

（2）CouponChecker类，来进行优惠券的校验

// @Service 不需要在这里让springboot容器托管
public class CouponChecker {

//    @Autowired
    private IMoneyDiscount iMoneyDiscount;

    private Coupon coupon;
    private UserCoupon userCoupon;
// 这里在构造方法中进行传入进来
    public CouponChecker(Coupon coupon, UserCoupon userCoupon, IMoneyDiscount iMoneyDiscount) {
        this.coupon = coupon;
        this.userCoupon = userCoupon;
        this.iMoneyDiscount = iMoneyDiscount;
    }
    // 省略部分校验方法逻辑代码......
}

这种方法是可以解决我们上面提到的那个单例模式存在的问题的，但是这种方法可能不是很完美，我们还有更好的解决方法

2、使用@Scope注解

这里具体的应用方案好像在这里并不是很实用，具体使用方法我想了一下，不知道怎么使用！！！讲一下@Scope注解是怎么使用的吧

（1）实体类代码

@Getter
@Setter
@Component
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class Test {
    private String name;
}

（2）controller层代码

@RestController
@RequestMapping(value = "/test")
public class TestController {

    @Autowired
    private Test test;

    @GetMapping(value = "")
    public void getDetail() {
        System.out.println(this.test);
    }
}

注意：这里只是@Scope注解的一个使用，具体怎么在那个业务场景下使用，我这里还暂时没有想到很好的办法！！！

 内容出处：七月老师《从Java后端到全栈》视频课程

七月老师课程链接：https://class.imooc.com/sale/javafullstack