关于设计模式:一天一个设计模式策略模式

蕴含角色

• context 策略使用者
• strategy 策略 (行为) 接口
• strategyImpl 策略的具体实现，通常这些实现也叫算法族

场景案例

demo1- 佣金核算

假如当初有三种业绩类型 (A,B,C) 须要核算佣金, 通过业务剖析, 三种核算过程都蕴含以下步骤:

• 查问元数据
• 清空重置上一次佣金计算
• 核算佣金
• 判断佣金归属

个别的做法是定义一个核算接口, 接口中定义上述办法, 而后实现核算接口, 在不同的接口实现类中实现相应的细节

// 核算接口
public interface ICalculate{query();
    clear();
    calculate();
    belong();}

// A 类型业绩核算
public class ACalculate implements ICalculate{
    // A 类型具体实现
    query();
    clear();
    calculate();
    belong();}

// B 类型业绩核算
public class BCalculate implements ICalculate{
    // B 类型具体实现
    query();
    clear();
    calculate();
    belong();}
 // 其余类型...

上述写法中, 存在一些问题:

• 如果 C 类型中没有 clear 清空逻辑呢?
• 能够在 C 类中不去实现 clear()办法
• 如果前期业务变更, 不须要 belong()办法了呢. 新增的类型能够不做具体实现, 已有的类型呢? 须要一一删除 belong()办法
• 如果前期新增了逻辑呢? 如: 核算团队业绩, 计算指标完成率
• 须要大量改变已实现的代码
• 因为政策变动,A,B,C 采纳全新对立的 query 查问,clear 清空逻辑, 核算和归属逻辑不同
• 最后各种类型的业绩核算, 查问清空等逻辑不同, 所以实现细节全副放在了核算类中, 现在许多办法能够共用, 就从新定义接口, 并实现 query/clear 新的逻辑, 而后在业绩核算类中注入

这些是工作中实在遇到的状况, 问题不言而喻:

• 耦合度高: 算法的实现与算法使用者耦合
• 代码复用低: 如果不同核算类型中用到雷同逻辑, 只能复制粘贴
• 拓展性太差: 在核算过程中新增和删除某个环节, 会批改大量代码
• 代码不足设计, 档次凌乱.

思考:

• 是否将核算过程中用到的核算环节与核算类分来到?
• 如果办法能够共用, 在核算类中能够间接注入接口实现
• 即便不能共用, 批改或新增核算环节时不须要改变核算类, 代码档次更清晰了
• 是否将这些办法形象成接口?
• 依据核算类型的业务需要, 这些办法能够有不同的实现
• 核算的环节将不再固定, 能够是任意步骤. 新增核算环节只须要定义新的行为接口

// 应用策略模式优化
// 1. 将核算环节形象为行为接口, 即核算过程有哪些行为
// 2. 行为接口能够有不同的具体实现, 这些实现类能够看成是一个算法族
// 3. 通过组合的形式, 使核算过程变动多样

// 查问策略
public interface Query{query();
}
// 查问策略算法族
public class TypeAQuery{query(){//typeA logic}
}
public class TypeBQuery{query(){//typeB logic}
}

// 清空策略
public interface Clear{clear();
}

 '其余策略(行为) ...'

// 业绩类型 A 的核算
public class ACalculate {
    // 自定义核算环节, 自定义核算环节具体实现
    private Query query;
}

// 业绩类型 B 的核算
public class BCalculate {
    // 自定义核算环节
    private Query query;
    private Clear clear;
}

// 调用过程中, 通过 set()办法能够动静替换策略的实现