设计模式–策略模式

标签：设计模式   java   策略模式   

策略模式，你有多少个if-else，就有可以写多少个策略模式——只要他值得

策略模式，又是一个我几乎在各个角落都有过使用的模式。因为，他可以说把最常规的if-else给“面向对象化”了，封装了算法。换句话说，当你有if-else的代码块的时候，理论上来说，都可以变成一个策略模式，当然，这只是打个夸张的比方，因为设计模式的劣势就在于相对复杂化代码结构，思路结构化为非过程化，所以只有值得优化为的if-else块使用策略模式才有价值。

〇 【业务场景】———————————

手头有一个管理系统，其中有三种权限，分别为ABC，当A登录后，显示员工信息；当B登录后，显示库存信息；当C登录后，显示财务信息。目前系统只有三个身份，以后走同样一个入口进去的身份会更多。

Ⅰ 【分析阶段】———————————

A来就这样，B进来就那样，C进来就这样那样.. 这个如果第一时间想到在登录业务那里进行if-else判断，那么恭喜你，距离策略模式很近了！怎么了，没这么简单？就是这么简单！这回我先放代码了

/**
 * 登录业务逻辑处理类，这里采用的struts2思路举例
 * 这个LoginService相当于是受LoginAction的调用，所以返回String类型的返回页标识
 *
 */
public class LoginService {

    /**
     * Action中就会调用这个方法
     * @param user
     * @return
     */
    public String getPageByIdentity(User user){
        
        //一些其他的操作
        doSth();
        
        //要根据用户身份获取对应的响应页面
        if(user.getIdentity()==1){
            
            //读取数据库等等操作，准备人事部门数据
            prepareDataForHR();
            //人事部门所独有的业务处理
            hrOtherService();
            //返回成功页面
            return "HR";
        }else if(user.getIdentity()==2){
            //读取数据库等等操作，准备销售部门数据
            prepareDataForSale();
            //销售部门所独有的业务处理
            saleOtherService();
            //返回成功页面
            return "SALE";
        }else if(user.getIdentity()==3){
            //读取数据库等等操作，准备财务部门数据
            prepareDataForFinace();
            //财务部门所独有的业务处理
            finaceOtherService();
            //返回成功页面
            return "FINACE";
        }else{
            return "ERROR";
        }
    }
}

这样思路没问题，但是很明显：代码冗杂，一旦扩展新的权限，或者复杂化现有的业务，将会反复变动这段代码。所以，换用策略模式：

Ⅱ【设计阶段】——————————————————-

public class LoginService {

public String getPageByIdentity(User user){

        //一些其他的操作
        doSth();

        //这里开始将if-else逻辑判断委派给策略模式的执行器
        return LoadStrategyExcutor.execute(user);
    }
}

/**
* 策略执行类，这里对用的身份进行判断，然后映射到不同的模式
*/
public class LoadStrategyExcutor {

    public static String execute(User user){

        IdentityLoadService loadStrategy = null;

        switch(user.getIdentityCode()){
            case 1 : loadStrategy = new UserALoadService();
                break;
            case 2 : loadStrategy = new UserBLoadService();
                break;
            case 3 : loadStrategy = new UserCLoadService();
                break;
            default: break;
        }

    return loadStrategy.doService();
    }
}

public class UserALoadService implements IdentityLoadService {
    @Override
    public String doService() {
        //读取数据库等等操作，准备人事部门数据
        prepareDataForHR();
        //人事部门所独有的业务处理
        hrOtherService();
        //返回成功页面
        return "HR";
    }
}

public class UserBLoadService implements IdentityLoadService {
    @Override
    public String doService() {
        //读取数据库等等操作，准备销售部门数据
        prepareDataForSale();
        //销售部门所独有的业务处理
        saleOtherService();
        //返回成功页面
        return "SALE";
    }
}

public class UserCLoadService implements IdentityLoadService {
    @Override
    public String doService() {
        //读取数据库等等操作，准备财务部门数据
        prepareDataForFinace();
        //财务部门所独有的业务处理
        finaceOtherService();
        //返回成功页面
        return "FINACE";
    }
}

Ⅲ【核查阶段】———————————————————–

这个分析起来比较清晰了：

1. 代码职责分工明确，不同的业务变更修改不同的java类，便于开发与管理；
2. 新增业务只需新增实现接口的实现类即可，同时在Excutor中进行分发；

Ⅳ【反思】———————————————————–
这时候我们来看看图：

大家在这里注意到，我将原本在LoginService中的if-else语句判断挪到了LoadStrategyExcutor中，原本还有一种做法，就是将LoadStrategyExcutor中的switch-case挪回到LoginService中，直接让LoginService来做判断，这样是否可以呢？

首先从功能上来说，当然没有区别，系统会正常运转。那区别在哪？主要是一个“职责划分”问题，在面向对象编程里面，重在一个解耦合与委派原则，希望能够将“不属于自己所管理”的部分不交给自己管理，

在这里，可以发现LoginService充当的是client，其他几个类完全输入“策略模式”的内部成员。LoginService通过一个LoadStrategyExcutor.execute(user) 来调用整个“策略模式”模块，这样，策略模式模块接收LoginService传递来的参数（正统一点说法是上下文Context），隔离到自己的区域处理业务逻辑，最终返回处理结果。

设计模式–策略模式

标签：设计模式   java   策略模式   

原文地址：http://blog.csdn.net/yangxy81118/article/details/38872413