关于java:工作中的设计模式-策略模式

前言

策略模式是一种行为设计模式，它能让你定义一系列算法，并将每种算法别离放入独立的类中，以使算法的对象可能互相替换。

应用场景

策略模式在工作中应用的绝对是比拟多的，像领取场景，计费场景，优惠场景，流动处分、用户等级等等。

当然也有很多直白的说法，就是替换一大堆的 if else。

if (x == aaa) {// 200 行代码} else if (x == bbb) {// 200 行代码} else if (x == ccc) {// 200 行代码}

依照下面的 if else 逻辑，其中 aaa、bbb、ccc 就是不同的策略。而应用策略模式的目标，就是当又减少了 ddd、eee 等等的时候，更不便的扩大。

这里以工作中遇到的场景举例：

这里抉择应用理财储蓄场景中的计费策略举例：
在理财储蓄场景中，须要每日给用户发放利息，同时用户分为普通用户、持卡用户，他们有别离的利率以及计息形式。

很显著，在计费时要应用策略模式，依照以下模式进行开发。

应用形式

定义计算接口

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 判断策略，或者保护在数据库中。

总结

本文介绍了在工作中应用策略模式，总结一下常常应用到的场景：

1. 领取形式的抉择：微信、支付宝、银联等等
2. 计费策略不同：不同的用户计费形式不同（免费 / 运费等）
3. 流动规定抉择：不同的流动走不同计算的逻辑
4. 计息形式不同：不同的用户（产品）计算利息的形式不同
   …

更多的就须要小伙伴去发现和总结了。

渔、就在这里，能不能打到鱼，那就靠急躁了。
加油

相干材料

1. 《深刻设计模式》：https://refactoringguru.cn/design-patterns
2. 封面图：https://refactoringguru.cn/design-patterns/strategy

相干举荐

• 工作中的设计模式 —— 原型模式
• Spring 是如何解决循环依赖的？
• Spring 自调用事务生效，你是怎么解决的？