【设计模式】策略模式

策略模式是一种很常用的模式，尽管他有一些缺点，但是在我们日常代码中依旧经常用到，另外大家可以看Spring的AopProxy就有用到，今天比较晚了，下次抽时间给大家带来那段源码解析。

    首先来看策略模式的定义：定义一组算法，将每个算法都封装 起来，并且使它们之间可以互换。这里依旧举例来说明：假定现有需求，对于用户的各种不同行为增加不同的积分，比如用户登录一次增加5积分，用户注册增加15积分，这就是一个很典型的策略模式的场景。接下来来看类图：

    由图中可以看到策略模式的角色分为：

• 抽象策略角色（MemberPointProcessor），该角色为一个接口类，抽象出计算方法，所有具体策略角色都实现此接口。
• 具体实现策略角色（MemberRegistPointProcessor等），该角色为对于抽象策略角色的具体实现。
• 上下文（MemberPointContext）这个角色主要对外做一层封装，可不要，想比如前面说的AopProxy那块代码里其实就是没有这个角色的。

下面来看具体代码实现：

    首先抽象策略角色MemberPointProcessor：

public interface MemberPointProcessor {
    /**
     * 给用户增加积分
     */
    void addProcessor();
}

    下面为具体策略实现：

public class MemberCertificationPointProcessor implements MemberPointProcessor {
    public void addProcessor() {
        System.out.println("用户正在执行实名认证操作，给用户增加20积分");
    }
}
public class MemberLoginPointProcessor implements MemberPointProcessor {
    public void addProcessor() {
        System.out.println("用户正在执行登录操作，给用户增加5积分");
    }
}
public class MemberRegistPointProcessor implements MemberPointProcessor {
    public void addProcessor() {
        System.out.println("用户正在执行注册操作，给用户增加15积分");
    }
}

    接下来是上下文角色：

public class MemberPointContext {
    /** 策略类 */
    private MemberPointProcessor memberPointProcessor;

    public MemberPointContext(MemberPointProcessor memberPointProcessor) {
        this.memberPointProcessor = memberPointProcessor;
    }
    /**
     * 执行策略方法
     */
    public void process() {
        this.memberPointProcessor.addProcessor();
    }
}

    最后是场景类：

public class MemberOperationService {
    /**
     * 给用户增加积分
     */
    public void addPoint(MemberBehaviorEnum memberBehavior) {
        switch (memberBehavior) {
            case REGIST:
                new MemberPointContext(new MemberRegistPointProcessor()).process();
                break;
            case LOGIN:
                new MemberPointContext(new MemberLoginPointProcessor()).process();
                break;
            case CERTIFICATION:
                new MemberPointContext(new MemberCertificationPointProcessor()).process();
                break;
            default:
                break;
        }
    }
}
//场景类中用到的枚举
public enum MemberBehaviorEnum {
    REGIST("注册"),
    LOGIN("登录"),
    CERTIFICATION("实名认证");

    private String message;

    MemberBehaviorEnum(String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }
}

    接下来调用方法测试：

public static void main(String[] args) {
    MemberOperationService service = new MemberOperationServiceImpl();
    service.addPoint(MemberBehaviorEnum.REGIST);
    service.addPoint(MemberBehaviorEnum.LOGIN);
    service.addPoint(MemberBehaviorEnum.CERTIFICATION);
}

    执行结果：

用户正在执行注册操作，给用户增加15积分
用户正在执行登录操作，给用户增加5积分
用户正在执行实名认证操作，给用户增加20积分

总结：

优点：

1. 由调用者选择具体策略，可自由切换（也是缺点，下面说道），比如某天登录要涨20分了，可以直接让登录的地方选择增加20分的那个算法。
2. 避免过多的if()…else if()…。平常我们代码中如果条件判断超过3的把，就可以考虑策略模式，使代码可读性更高。
3. 扩展性好，比如要新增用户签到，只需增加一种策略，并且在场景类中加一个case即可，不会对原有其他逻辑造成改动。

缺点：

1. 类数量增多，每种策略都是一个类，导致类数量很多，而且比如有的算法，过段时间过时了，又会造成算法新增
2. 违背迪米尔法则，即上面所说的优点第一点，场景类需要很清楚的了解每个策略是干嘛的来觉得调用谁，对于场景类的知识依赖度过高

改进办法：参考AopProxy那块的实现，将策略模式和工厂模式结合使用，可解决缺点的第二条。

今天先到这里，下次给大家带来AopProxy那块源码解读。

---

欢迎关注个人博客：blog.scarlettbai.com