哎，从前我也很喜欢if/else链式的写法。这是一次SAO行动。例如，举个简单易懂的栗子：一般来说，我们正常的后台管理系统都有所谓角色的概念。不同的管理员拥有不同的权限，可以进行不同的操作。例如：系统管理员（ROLE_ROOT_ADMIN）：有A操作权限命令管理员（ROLE_ORDER_ADMIN）：有B普通用户有操作权限（ROLE_NORMAL）：比如一个用户进来有C操作权限，我们需要根据他的行为来判断他的行为到不同用户的角色。这时SAO代码出现：publicclassJudgeRole{publicStringjudge(StringroleName){Stringresult="";if(roleName.equals("ROLE_ROOT_ADMIN")){//系统管理员有A权限result="ROLE_ROOT_ADMIN:"+"hasAAApermission";}elseif(roleName.equals("ROLE_ORDER_ADMIN")){//订单管理员有B权限result="ROLE_ORDER_ADMIN:"+"hasBBBpermission";}elseif(roleName.equals("ROLE_NORMAL")){//普通用户有C权限result="ROLE_NORMAL:"+"hasCCCpermission";}else{result="XXX";}returnresult;}}这样当系统有几十个角色的时候，那几十个if/else的嵌套可以说是很酸了。。。很不优雅，很难实现别人读；二是如果以后比较复杂，或者要加条件，就不好扩展了；如果代码被更改，旧的功能必须重新测试，这不是很疯狂......所以，如果你不阅读以下内容，你通常如何处理这些令人头疼的问题if/else语句呢？当然有人会说用switch/case写是不是更优雅？答案是：没有区别！接下来简单说一下几种改进方法，让if/else不至于满天飞。明明是有对应关系的，那为什么不用学过的枚举呢？首先定义一个publicinterfaceRoleOperation，表示不同角色可以做的操作：publicinterfaceRoleOperation{Stringop();//表示某个角色可以做哪些op操作}接下来，我们将枚举不同角色的所有情况，定义一个枚举不同角色不同权限的classRoleEnum：接下来调用就变异常了很简单，一行代码，if/else就没有了：publicclassJudgeRole{publicStringjudge(StringroleName){//一行代码搞定！之前的if/else没有了！returnRoleEnum.valueOf(roleName).op();}}并且这样以后如果我想扩展条件，只需要在枚举类中添加代码，而不需要改变之前的代码。这不是很稳定吗？!除了用枚举来淘汰if/else，工厂模式也可以实现。有一个工厂模式。为什么不使用不同的分支来做不同的事情呢？显然，它提供了一个使用工厂模式的机会。我们只需要分别定义不同的情况。然后去工厂类聚合。首先，针对不同的角色，分别定义其业务类：接下来，写一个工厂类RoleFactory，将以上不同的角色聚合起来：接下来，借助上面的工厂，业务代码调用只需要一行代码，if/else也去掉了：publicclassJudgeRole{publicStringjudge(StringroleName){//一行代码搞定！之前的if/else没有了！returnRoleFactory.getOp(roleName).op();}}这样方便以后扩展条件。只需要增加新的代码，而无需触及之前的业务代码，非常符合“开闭原则”。来吧，让我们继续。除了工厂模式，策略模式也可以一试。为什么不用策略模式和工厂模式来写区别呢？在上面工厂模式代码的基础上，遵循策略模式的思路，我们也创建一个所谓的策略上下文类，这里命名为RoleContext：显然，上面传入的参数操作代表了不同的“策略”。我们可以通过在业务代码中传入不同的角色来得到不同的运行结果：
