策略模式，你有多少个if-else，就有可以写多少个策略模式——只要他值得
策略模式，又是一个我几乎在各个角落都有过使用的模式。因为，他可以说把最常规的if-else给“面向对象化”了，封装了算法。换句话说，当你有if-else的代码块的时候，理论上来说，都可以变成一个策略模式，当然，这只是打个夸张的比方，因为设计模式的劣势就在于相对复杂化代码结构，思路结构化为非过程化，所以只有值得优化为的if-else块使用策略模式才有价值。
〇 【业务场景】———————————
手头有一个管理系统，其中有三种权限，分别为ABC，当A登录后，显示员工信息；当B登录后，显示库存信息；当C登录后，显示财务信息。目前系统只有三个身份，以后走同样一个入口进去的身份会更多。
Ⅰ 【分析阶段】———————————
A来就这样，B进来就那样，C进来就这样那样.. 这个如果第一时间想到在登录业务那里进行if-else判断，那么恭喜你，距离策略模式很近了！怎么了，没这么简单？就是这么简单！这回我先放代码了
如果是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";
}
}
Ⅲ【核查阶段】———————————————————–
这个分析起来比较清晰了：
- 代码职责分工明确，不同的业务变更修改不同的java类，便于开发与管理；
- 新增业务只需新增实现接口的实现类即可，同时在Excutor中进行分发；
Ⅳ【反思】———————————————————–
这时候我们来看看图：
大家在这里注意到，我将原本在LoginService中的if-else语句判断挪到了LoadStrategyExcutor中，原本还有一种做法，就是将LoadStrategyExcutor中的switch-case挪回到LoginService中，直接让LoginService来做判断，这样是否可以呢？
首先从功能上来说，当然没有区别，系统会正常运转。那区别在哪？主要是一个“职责划分”问题，在面向对象编程里面，重在一个解耦合与委派原则，希望能够将“不属于自己所管理”的部分不交给自己管理，
在这里，可以发现LoginService充当的是client，其他几个类完全输入“策略模式”的内部成员。LoginService通过一个LoadStrategyExcutor.execute(user) 来调用整个“策略模式”模块，这样，策略模式模块接收LoginService传递来的参数（正统一点说法是上下文Context），隔离到自己的区域处理业务逻辑，最终返回处理结果。