工作中的设计模式 —— 策略模式
共 3544字，需浏览 8分钟
·
2021-04-10 09:39
前言
策略模式是一种行为设计模式，它能让你定义一系列算法，并将每种算法分别放入独立的类中，以使算法的对象能够相互替换。
1
使用场景
策略模式在工作中使用的相对是比较多的，像支付场景，计费场景，优惠场景，活动奖励、用户等级等等。
当然也有很多直白的说法，就是替换一大堆的 if else。
if (x == aaa) {
// 200 行代码
} else if (x == bbb) {
// 200 行代码
} else if (x == ccc) {
// 200 行代码
}
按照上面的 if else 逻辑，其中 aaa、bbb、ccc 就是不同的策略。而使用策略模式的目的，就是当又增加了 ddd、eee 等等的时候，更方便的扩展。
这里以工作中遇到的场景举例：
这里选择使用理财储蓄场景中的计费策略举例：在理财储蓄场景中，需要每日给用户发放利息，同时用户分为普通用户、持卡用户，他们有分别的利率以及计息方式。
很明显，在计费时要使用策略模式，按照以下模式进行开发。
2
使用方式
定义计算接口
public interface RevenueCalculator {
RevenueDTO calculate(BigDecimal asset);
}
定义不同的计算实现
对外暴露的是一个接口，而具体的实现，则需要自己去扩展。下面展示了三个实现。
@Component
public class DefaultRevenueCalculator implements RevenueCalculator {
@Override
public RevenueDTO calculate(BigDecimal asset) {
return null;
}
}
@Component
public class StepRateGeneralRevenueCalculator implements RevenueCalculator {
@Override
public RevenueDTO calculate(BigDecimal asset) {
return null;
}
}
@Component
public class StepRateHoldCardRevenueCalculator implements RevenueCalculator {
@Override
public RevenueDTO calculate(BigDecimal asset) {
return null;
}
}
当然这里 StepRateHoldCardRevenueCalculator 和 StepRateGeneralRevenueCalculator 有抽象相同的业务逻辑，也可以抽出来一层工厂方法。
这些在这里都不是重点。
通过实现接口的方式，在后面有新的计费策略时，就写一个新的实现类就可以了。
现在的问题是，我如何确定哪个用户走那一套策略呢？
策略类
public enum UserTypeEnum implements BaseEnum {
/**
* OWealth 原始计息方式
*/
DEFAULT_USER(-1, "原计息方式", "defaultRevenueCalculator"),
/**
* 普通用户
*/
GENERAL_USER(0, "默认用户", "stepRateGeneralRevenueCalculator"),
/**
* 持卡用户
*/
HOLD_CARD_USER(1, "持卡用户", "stepRateHoldCardRevenueCalculator"),
;
// 省略代码
}
public class RevenueCalculatorFactory {
public static RevenueCalculator getCalculator(UserTypeEnum userType) {
return SpringContextHolder.getBean(userType.getServiceName());
}
}
这里只是介绍了使用枚举维护用户类型和策略实现的关系，也可以在这里面写 if else 判断策略，或者维护在数据库中。
3
总结
本文介绍了在工作中使用策略模式，总结一下经常使用到的场景：
支付方式的选择：微信、支付宝、银联等等 计费策略不同：不同的用户计费方式不同（收费/运费等） 活动规则选择：不同的活动走不同计算的逻辑 计息方式不同：不同的用户（产品）计算利息的方式不同 ...
更多的就需要小伙伴去发现和总结了。
渔、就在这里，能不能打到鱼，那就靠耐心了。
加油
相关资料
- <End /> -
历史文章 ｜ 相关推荐
