消灭又臭又长的if-else

  由于目前工作岗位的原因，项目还是09年建立的，历史遗留问题也比较多，加上开发规范并不是很完善，项目中有的单个方法达到成百上千行，if-else更是连续写十几个也不累。

  作为强迫症真的受不了，另一方面，代码的可读性以及可扩展性大大降低。在接下来的文章中，将结合不同的场景介绍几种优化if-else的常见方案。

这种场景很常见，在开发过程中，碰到if-else的时候，可以想一下，是不是可以用三目运算符来替换？当然可以，不然我写文章干嘛，哈哈哈

//优化前
public static void before(boolean condition){
    int temp;
    if (condition) {
 temp = 1;
    } else{
 temp = 2;
    }
    System.out.println(temp);
}
//优化后
public static void after(boolean condition){
    int temp = condition ? 1 : 2;
    System.out.println(temp);
}

使用枚举类，完成对不同分支的逻辑判断，通过枚举便于集中管理逻辑条件，维护起来也更得心应手。代码如下：

//优化前
public static void before(String code) {
    String msg = null;
    if ("00001".equals(code)) {
 msg = "缓存数据不能为空";
    } else if ("00002".equals(code)) {
 msg = "数据格式异常";
    }
    System.out.println(msg);
    }
//优化后
public enum CacheEnums {
    CACHE_DATA_IS_NULL("00001", "缓存数据不能为空"),
    DATA_FORMATE_EXCEPTION("00002", "数据格式异常");
    private String code;
    private String msg;
​
    CacheEnums(String code, String msg) {
 this.code = code;
 this.msg = msg;
    }
​
    public String getCode() {
 return code;
    }
​
    public void setCode(String code) {
 this.code = code;
    }
​
    public String getMsg() {
 return msg;
    }
​
    public void setMsg(String msg) {
 this.msg = msg;
    }
​
    public static CacheEnums of(String code){
 for (CacheEnums temp : CacheEnums.values()) {
     if (temp.getCode().equals(code)) {
  return temp;
     }
 }
 return null;
    }
}

优化后的代码，在想获取msg时，一句话搞定，再也不用写一堆if-else了

//优化后
public static void after(String code) {
    String msg = CacheEnums.of(code).getCode();
    System.out.println(msg);
}

在业务逻辑开发过程中，经常会写一些方法，会校验参数合法性，以及是否符合业务逻辑等检查，一旦不合条件，就会进行return或者是抛异常。有些同学的写法：

//优化前
public static int before(boolean condition1,boolean condition2) {
    if (!condition1){
 return 0;
    }else if (condition2){
 return 1;
    }else{
 return 99;
    }
}
//优化后
public static int after(boolean condition1,boolean condition2) {
    if (condition1){
 return 0;
    }
    if (condition2){
 return 1;
    }
    return 99;
}

能够用的上策略模式的场景相对就更加特殊一些了，举个常见的例子，一个超市收银系统中的结算模块中会有很多种结算方式：双十一打折活动、满减活动、会员积分兑换消费券等等。他们都属于结算业务，那么就可以通过策略模式，设计不同的结算方式，达到解耦合和易扩展的目的。
接下来的代码以我项目中实际开发中用到的例子来说明，本次改造点是：在原有发送请求的的方法中增加将消息转发到其他平台的功能。考虑到以后可能会增加更多的平台，因此，这里采用策略模式，方便未来的功能扩展。以下为简版策略模式：

public interface Route {
​
    //定义处理方法
    void handler(Object object);
}

public class RouteContext {
​
    //策略模式的顶层接口
    private Route route;
​
    public RouteContext(Route route) {
 this.route = route;
 this.init();
    }
​
    //调用具体的策略中handler方法
    public void handler(Route route, Object object) {
 this.route = route;
 route.handler(object);
    }
​
    public void init() {
 //做一些数据的初始化
    }
}

public class MQType implements Route{
    @Override
    public void handler(Object object) {
 //这里是业务逻辑
    }
}

public class OtherType implements Route{
    @Override
    public void handler(Object object) {
 //这里是业务逻辑
    }
}

  搞定，这样就能够实现不同业务逻辑对应不同的实现类，再也不用一大坨代码揉在一块了，每一种路由方式都可以独立维护且易扩展，调用方也是无感知的。