前言
接上文继续 ，这时候产品又来了一个新需求（PS：这是一个假需求，自己遐想的）。
我们来了新出一个需求：需要优惠券里面添加一个功能，优惠券新出折扣优惠券，可以打折。我去！！！这不是会员卡的功能吗？要不把会员卡的内容COPY一份
对策
拷贝一份好像马上就解决了问题。但是接下来同一份逻辑就要维护两份了。那有什么方法可以把计算方法抽离出来然后公用呢。
策略模式好像解决该问题。
策略模式
策略模式
其思想是针对一组算法，将每一种算法都封装到具有共同接口的独立的类中，从而是它们可以相互替换。策略模式的最大特点是使得算法可以在不影响客户端的情况下发生变化，从而改变不同的功能。
在我们这里主要就是封住我们的优惠算法啦，试试看。
coding中。。。
30分钟后，代码写完了，见代码如下文
/**
* 优惠策略
*/
public interface BenefitMethod {
double getMoney(double money);
}
/**
* 优惠券策略
*/
public class CouponMethod implements BenefitMethod {
private final double storeValue;
private double needPay;
public CouponMethod(double needPay, double storeValue) {
this.needPay = needPay;
this.storeValue = storeValue;
}
@Override
public double getMoney(double money) {
return money >= needPay ? storeValue : 0;
}
}
/**
* 折扣策略
*/
public class DisCountMethod implements BenefitMethod {
private double discount;
/**
* 折扣策略，传入金额为m，折扣Z，面值为m-mz
*
* @param discount
*/
public DisCountMethod(double discount) {
this.discount = discount;
}
@Override
public double getMoney(double money) {
return money - discount * money;
}
}
/**
* 储值折扣策略
*/
public class DisCountStoreValueMethod implements BenefitMethod {
private double discount;
private double storeValue;
/**
* 传入金额为m，折扣Z，储值n，总价为mz；
* 储值n大于mz，则储值面值为mz；
* 储值n小于等于mz，则为储值面值为n;
* 当然优惠部分也是该会员卡的面值 即 （m-mz）+ mz = m 和传入金额一样，即使全部抵扣 或者是储值n小于等于mz， （ m-mz）+ n
*
* @param storeValue 储值
* @param discount 折扣
*/
public DisCountStoreValueMethod(double storeValue, double discount) {
this.storeValue = storeValue;
this.discount = discount;
}
@Override
public double getMoney(double money) {
/**
* 传入金额为m，折扣Z，储值n，总价为mz；
* 储值n大于mz，则储值面值为mz；
* 储值n小于等于mz，则为储值面值为n;
* 当然优惠部分也是该会员卡的面值 即 （m-mz）+ mz = m 和传入金额一样，即使全部抵扣 或者是储值n小于等于mz， （ m-mz）+ n
*/
double allMoney = money * discount;
//这里全部钱都被优惠掉了 储值也算优化
if (storeValue > allMoney) {
return money;
}
return money - allMoney + storeValue;
}
}
/**
* 储值策略
*/
public class StoreValueMethod implements BenefitMethod {
private double storeValue;
/**
* 储值策略，传入金额为m，储值n大于m，则面值为m，储值n小于等于m，则为面值为n
*
* @param storeValue 储值
*/
public StoreValueMethod(double storeValue) {
this.storeValue = storeValue;
}
@Override
public double getMoney(double money) {
return money >= storeValue ? storeValue : money;
}
}
上文写完了四种策略，四种策略对实现了优惠策略接口。接下来，我就是要试试可否动态选择对应优化方式，继续Coding
/**
* 策略模式版 优惠
* 对应 https://blog.csdn.net/u011850446/article/details/88064551
* Benefit 相当于Context
* BenefitMethod 相当于 Strategy
* BenefitMethod的子类 相当于 Strategy子类
* 区别在于 一般是我们自己传入相对method 比如public Benefit（BenefitMethod method）
* 这里是由后台配置更加灵活
*/
public class Benefit {
/**
* 这里是其他信息
* 和本题无关了字段省略
*/
/**
* 折扣
*/
private double discount;
/**
* 储值
*/
private double storeValue;
/**
* 满多少
*/
private double howMuchLessNeedPay;
/**
* 减多少
*/
private double howMuchLessValue;
/**
* 优惠方式
* 上个版本中是有一个会员卡类型
* 但是这个版本需要这里后端来告诉我们这个优惠方式了
* 平时自己代码中可以通过传值方式
*/
private int benefitType;
/**
* 储值卡
*/
private static final int TYPE_STORE_VALUE = 0;
/**
* 折扣卡
*/
private static final int TYPE_DISCOUNT = 1;
/**
* 储值折扣卡
*/
private static final int TYPE_STORE_VALUE_DISCOUNT = 2;
/**
* 优惠券
*/
private static final int TYPE_COUPON = 3;
public double getBenefitValue(double money) {
BenefitMethod method = null;
switch (benefitType) {
case TYPE_STORE_VALUE:
method = new StoreValueMethod(storeValue);
break;
case TYPE_DISCOUNT:
method = new DisCountMethod(discount);
break;
case TYPE_STORE_VALUE_DISCOUNT:
method = new DisCountStoreValueMethod(storeValue, discount);
break;
case TYPE_COUPON:
method = new CouponMethod(howMuchLessNeedPay, howMuchLessValue);
break;
default:
break;
}
//没有优惠策略时 为0
if (method == null) {
return 0;
}
return method.getMoney(money);
}
}
总结
我们根据后台返回结果，计算出对应对优惠方式。优惠券和会员卡都能使用对方对方式，而且计算方式和优化类型都不耦合。对比与第一种方式，类多了。但是整理都代码量应该相对减少了。一般简单情况下，上文都已经足够。但是明显代码都是比较耦合的。但是这篇文章中写的内容是否可以优化优化，我们下文再续。