设计模式之策略模式
策略模式是一种行为模式,在我们编写代码时经常会发现适用于此设计模式的场景。它所能帮你解决的是场景,一般是具有同类可替代的行为逻辑算法场景。比如;根据下发渠道选择对应的下发方式(mq、esb、saturn)不同类型的交易方式(信用卡、支付宝、微信)、生成唯一ID策略(UUID、DB自增、DB+Redis、雪花算法、Leaf算法)等,都可以使用策略模式进行行为包装,供给外部使用。
策略模式也有点像三国演义中诸葛亮给刘关张的锦囊;
第一个锦囊:见乔国老,并把刘备娶亲的事情搞得东吴人尽皆知。
第二个锦囊:用谎言(曹操打荆州)骗泡在温柔乡里的刘备回去。
第三个锦囊:让孙夫人摆平东吴的追兵,她是孙权妹妹,东吴将领惧她三分。
四、案例场景模拟
图片
场景模拟;商品支付使用营销优惠券
这个场景几乎也是大家的一个日常购物省钱渠道,购买商品的时候都希望找一些优惠券,让购买的商品更加实惠。而且到了大促的时候就会有更多的优惠券需要计算那些商品一起购买更加优惠!!!
这样的场景有时候用户用起来还是蛮爽的,但是最初这样功能的设定以及产品的不断迭代,对于程序员👨💻开发还是不太容易的。因为这里包括了很多的规则和优惠逻辑,所以我们模拟其中的一个计算优惠的方式,使用策略模式来实现。
五、用一坨坨代码实现
这里我们先使用最粗暴的方式来实现功能
对于优惠券的设计最初可能非常简单,就是一个金额的抵扣,也没有现在这么多种类型。所以如果没有这样场景的经验话,往往设计上也是非常简单的。但随着产品功能的不断迭代,如果程序最初设计的不具备很好的扩展性,那么往后就会越来越混乱。
- 工程结构
itstack-demo-design-20-01
└── src
└── main
└── java
└── org.itstack.demo.design
└── CouponDiscountService.java
一坨坨工程的结构很简单,也是最直接的面向过程开发方式。 - 代码实现
public class CouponDiscountService {
public double discountAmount(int type, double typeContent, double skuPrice, double typeExt) {
// 1. 直减券
if (1 == type) {
return skuPrice - typeContent;
}
// 2. 满减券
if (2 == type) {
if (skuPrice < typeExt) return skuPrice;
return skuPrice - typeContent;
}
// 3. 折扣券
if (3 == type) {
return skuPrice * typeContent;
}
// 4. n元购
if (4 == type) {
return typeContent;
}
return 0D;
}
}
以上是不同类型的优惠券计算折扣后的实际金额。
入参包括;优惠券类型、优惠券金额、商品金额,因为有些优惠券是满多少减少多少,所以增加了typeExt类型。这也是方法的不好扩展性问题。
最后是整个的方法体中对优惠券抵扣金额的实现,最开始可能是一个最简单的优惠券,后面随着产品功能的增加,不断的扩展if语句。实际的代码可能要比这个多很多。
六、策略模式重构代码
接下来使用策略模式来进行代码优化,也算是一次很小的重构。
与上面面向流程式的开发这里会使用设计模式,优惠代码结构,增强整体的扩展性。
- 工程结构
itstack-demo-design-20-02
└── src
└── main
└── java
└── org.itstack.demo.design
├── event
│ └── MJCouponDiscount.java
│ └── NYGCouponDiscount.java
│ └── ZJCouponDiscount.java
│ └── ZKCouponDiscount.java
├── Context.java
└── ICouponDiscount.java
整体的结构模式并不复杂,主要体现的不同类型的优惠券在计算优惠券方式的不同计算策略。
这里包括一个借口类(ICouponDiscount)以及四种优惠券类型的实现方式。
最后提供了策略模式的上下文控制类处理,整体的策略服务。
2. 代码实现
2.1 优惠券接口
public interface ICouponDiscount<T> {
/**
* 优惠券金额计算
* @param couponInfo 券折扣信息;直减、满减、折扣、N元购
* @param skuPrice sku金额
* @return 优惠后金额
*/
BigDecimal discountAmount(T couponInfo, BigDecimal skuPrice);
}
定义了优惠券折扣接口,也增加了泛型用于不同类型的接口可以传递不同的类型参数。
接口中包括商品金额以及出参返回最终折扣后的金额,这里在实际开发中会比现在的接口参数多一些,但核心逻辑是这些。
2.2 优惠券接口实现
public class MJCouponDiscount implements ICouponDiscount<Map<String,String>> {
/**
* 满减计算
* 1. 判断满足x元后-n元,否则不减
* 2. 最低支付金额1元
*/
public BigDecimal discountAmount(Map<String,String> couponInfo, BigDecimal skuPrice) {
String x = couponInfo.get("x");
String o = couponInfo.get("n");
// 小于商品金额条件的,直接返回商品原价
if (skuPrice.compareTo(new BigDecimal(x)) < 0) return skuPrice;
// 减去优惠金额判断
BigDecimal discountAmount = skuPrice.subtract(new BigDecimal(o));
if (discountAmount.compareTo(BigDecimal.ZERO) < 1) return BigDecimal.ONE;
return discountAmount;
}
}
public class ZJCouponDiscount implements ICouponDiscount<Double> {
/**
* 直减计算
* 1. 使用商品价格减去优惠价格
* 2. 最低支付金额1元
*/
public BigDecimal discountAmount(Double couponInfo, BigDecimal skuPrice) {
BigDecimal discountAmount = skuPrice.subtract(new BigDecimal(couponInfo));
if (discountAmount.compareTo(BigDecimal.ZERO) < 1) return BigDecimal.ONE;
return discountAmount;
}
}
public class ZKCouponDiscount implements ICouponDiscount<Double> {
/**
* 折扣计算
* 1. 使用商品价格乘以折扣比例,为最后支付金额
* 2. 保留两位小数
* 3. 最低支付金额1元
*/
public BigDecimal discountAmount(Double couponInfo, BigDecimal skuPrice) {
BigDecimal discountAmount = skuPrice.multiply(new BigDecimal(couponInfo)).setScale(2, BigDecimal.ROUND_HALF_UP);
if (discountAmount.compareTo(BigDecimal.ZERO) < 1) return BigDecimal.ONE;
return discountAmount;
}
}
public class NYGCouponDiscount implements ICouponDiscount<Double> {
/**
* n元购购买
* 1. 无论原价多少钱都固定金额购买
*/
public BigDecimal discountAmount(Double couponInfo, BigDecimal skuPrice) {
return new BigDecimal(couponInfo);
}
}
以上是四种不同类型的优惠券计算折扣金额的策略方式,可以从代码中看到每一种优惠方式的优惠金额。
2.3 策略控制类
public class Context<T> {
private ICouponDiscount<T> couponDiscount;
public Context(ICouponDiscount<T> couponDiscount) {
this.couponDiscount = couponDiscount;
}
public BigDecimal discountAmount(T couponInfo, BigDecimal skuPrice) {
return couponDiscount.discountAmount(couponInfo, skuPrice);
}
}
策略模式的控制类主要是外部可以传递不同的策略实现,在通过统一的方法执行优惠策略计算。
另外这里也可以包装成map结构,让外部只需要对应的泛型类型即可使用相应的服务。
3. 测试验证
3.1 编写测试类(直减优惠)
@Test
public void test_zj() {
// 直减;100-10,商品100元
Context<Double> context = new Context<Double>(new ZJCouponDiscount());
BigDecimal discountAmount = context.discountAmount(10D, new BigDecimal(100));
logger.info("测试结果:直减优惠后金额 {}", discountAmount);
}
「测试结果」
15:43:22.035 [main] INFO org.itstack.demo.design.test.ApiTest - 测试结果:直减优惠后金额 90
Process finished with exit code 0
3.2 编写测试类(满减优惠)
@Test
public void test_mj() {
// 满100减10,商品100元
Context<Map<String,String>> context = new Context<Map<String,String>>(new MJCouponDiscount());
Map<String,String> mapReq = new HashMap<String, String>();
mapReq.put("x","100");
mapReq.put("n","10");
BigDecimal discountAmount = context.discountAmount(mapReq, new BigDecimal(100));
logger.info("测试结果:满减优惠后金额 {}", discountAmount);
}
「测试结果」
15:43:42.695 [main] INFO org.itstack.demo.design.test.ApiTest - 测试结果:满减优惠后金额 90
Process finished with exit code 0
3.3 编写测试类(折扣优惠)
@Test
public void test_zk() {
// 折扣9折,商品100元
Context<Double> context = new Context<Double>(new ZKCouponDiscount());
BigDecimal discountAmount = context.discountAmount(0.9D, new BigDecimal(100));
logger.info("测试结果:折扣9折后金额 {}", discountAmount);
}
「测试结果」
15:44:05.602 [main] INFO org.itstack.demo.design.test.ApiTest - 测试结果:折扣9折后金额 90.00
Process finished with exit code 0
3.4 编写测试类(n元购优惠)
@Test
public void test_nyg() {
// n元购;100-10,商品100元
Context<Double> context = new Context<Double>(new NYGCouponDiscount());
BigDecimal discountAmount = context.discountAmount(90D, new BigDecimal(100));
logger.info("测试结果:n元购优惠后金额 {}", discountAmount);
「测试结果」
15:44:24.700 [main] INFO org.itstack.demo.design.test.ApiTest - 测试结果:n元购优惠后金额 90
Process finished with exit code 0
以上四组测试分别验证了不同类型优惠券的优惠策略,测试结果是满足我们的预期。
这里四种优惠券最终都是在原价100元上折扣10元,最终支付90元。
七、总结
以上的策略模式案例相对来说不并不复杂,主要的逻辑都是体现在关于不同种类优惠券的计算折扣策略上。结构相对来说也比较简单,在实际的开发中这样的设计模式也是非常常用的。另外这样的设计与命令模式、适配器模式结构相似,但是思路是有差异的。
通过策略设计模式的使用可以把我们方法中的if语句优化掉,大量的if语句使用会让代码难以扩展,也不好维护,同时在后期遇到各种问题也很难维护。在使用这样的设计模式后可以很好的满足隔离性与和扩展性,对于不断新增的需求也非常方便承接。
策略模式、适配器模式、组合模式等,在一些结构上是比较相似的,但是每一个模式是有自己的逻辑特点,在使用的过程中最佳的方式是经过较多的实践来吸取经验,为后续的研发设计提供更好的技术输出。