利用“充血枚举类型”消除if/else

2020-02-15 本文已影响0人半路和尚怎么出家

截取自：https://mp.weixin.qq.com/s/HEyPBwbQZVRbFL1ivruVbg

无处不在的 if else 牛皮癣

无论你的编程启蒙语言是什么，最早学会的逻辑控制语句一定是 if else，但是不幸的是它在你开始真正的编程工作以后，会变成一个损害项目质量的坏习惯。

几乎所有的项目都存在 if else 泛滥的问题，但是却没有引起足够重视警惕，甚至被很多程序员认为是正常现象。

首先我来解释一下为什么 if else 这个看上去人畜无害的东西是有害的、是需要严格管控的：

if else if ...else 以及类似的 switch 控制语句，本质上是一种 hard coding 硬编码行为，如果你同意“magic number 魔法数字”是一种错误的编程习惯，那么同理，if else 也是错误的 hard coding 编程风格；
hard coding 的问题在于当需求发生改变时，需要到处去修改，很容易遗漏和出错；
以一段代码为例来具体分析：

if ("3".equals(object.getString("type"))){
          String data = object.getString("data");
          Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score");
          Map param = new HashMap();
          param.put("phoneNumber", object.getString("mobile"));
          List<Dperson> list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param);
          if (list1 !=null){
              for (Dperson dperson:list1){
                  dperson.setZmScore(zmf);
                  personBaseDaoI.saveOrUpdate(dperson);
                  AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);
              }
          }
}

if ("3".equals(object.getString("type")))
- 显然这里的"3"是一个 magic number，没人知道 3 是什么含义，只能推测；
- 但是仅仅将“3”重构成常量 ABC_XYZ 并不会改善多少，因为 if (ABC_XYZ.equals(object.getString("type"))) 仍然是面向过程的编程风格，无法扩展；
- 到处被引用的常量 ABC_XYZ 并没有比到处被 hard coding 的 magic number 好多少，只不过有了含义而已；
- 把常量升级成 Enum 枚举类型呢，也没有好多少，当需要判断的类型增加了或判断的规则改变了，还是需要到处修改——Shotgun Surgery(霰弹式修改)
并非所有的 if else 都有害，比如上面示例中的 if (list1 !=null) { 就是无害的，没有必要去消除，也没有消除它的可行性。判断是否有害的依据：
- 如果 if 判断的变量状态只有两种可能性（比如 boolean、比如 null 判断）时，是无伤大雅的；
- 反之，如果 if 判断的变量存在多种状态，而且将来可能会增加新的状态，那么这就是个问题；
- switch 判断语句无疑是有害的，因为使用 switch 的地方往往存在很多种状态。

充血枚举类型——Rich Enum Type

正如前面分析呈现的那样，对于代码中广泛存在的状态、类型 if 条件判断，仅仅把被比较的值重构成常量或 enum 枚举类型并没有太大改善——使用者仍然直接依赖具体的枚举值或常量，而不是依赖一个抽象。

于是解决方案就自然浮出水面了：在 enum 枚举类型基础上进一步抽象封装，得到一个所谓的“充血”的枚举类型，代码说话：

实现多种系统通知机制，传统做法:

enum NOTIFY_TYPE {    email,sms,wechat;  }  //先定义一个enum——一个只定义了值不包含任何行为的“贫血”的枚举类型

if(type==NOTIFY_TYPE.email){ //if判断类型 调用不同通知机制的实现 
    。。。
}else if (type=NOTIFY_TYPE.sms){
    。。。
}else{
    。。。
}

实现多种系统通知方式，充血枚举类型——Rich Enum Type 模式:

enum NOTIFY_TYPE {    //1、定义一个包含通知实现机制的“充血”的枚举类型
  email("邮件",NotifyMechanismInterface.byEmail()),
  sms("短信",NotifyMechanismInterface.bySms()),
  wechat("微信",NotifyMechanismInterface.byWechat());  
  
  String memo;
  NotifyMechanismInterface notifyMechanism;
  
  private NOTIFY_TYPE(String memo,NotifyMechanismInterface notifyMechanism){//2、私有构造函数，用于初始化枚举值
      this.memo=memo;
      this.notifyMechanism=notifyMechanism;
  }
  //getters ...
}

public interface  NotifyMechanismInterface{ //3、定义通知机制的接口或抽象父类
    public boolean doNotify(String msg);
 
    public static NotifyMechanismInterface byEmail(){//3.1 返回一个定义了邮件通知机制的策的实现——一个匿名内部类实例
        return new NotifyMechanismInterface(){
            public boolean doNotify(String msg){
                .......
            }
        };
    }
    public static NotifyMechanismInterface bySms(){//3.2 定义短信通知机制的实现策略
        return new NotifyMechanismInterface(){
            public boolean doNotify(String msg){
                .......
            }
        };
    } 
    public static NotifyMechanismInterface byWechat(){//3.3 定义微信通知机制的实现策略
        return new NotifyMechanismInterface(){
            public boolean doNotify(String msg){
                .......
            }
        };
    }
}

//4、使用场景
NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg);

充血枚举类型——Rich Enum Type 模式的优势：
- 不难发现，这其实就是 enum 枚举类型和 Strategy Pattern 策略模式的巧妙结合运用；
- 当需要增加新的通知方式时，只需在枚举类 NOTIFY_TYPE 增加一个值，同时在策略接口 NotifyMechanismInterface 中增加一个 by 方法返回对应的策略实现；
- 当需要修改某个通知机制的实现细节，只需修改 NotifyMechanismInterface 中对应的策略实现；
- 无论新增还是修改通知机制，调用方完全不受影响，仍然是NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg);
与传统 Strategy Pattern 策略模式的比较优势：常见的策略模式也能消灭 if else 判断，但是实现起来比较麻烦，需要开发更多的 class 和代码量：
- 每个策略实现需单独定义成一个 class；
- 还需要一个 Context 类来做初始化——用 Map 把类型与对应的策略实现做映射；
- 使用时从 Context 获取具体的策略；
Rich Enum Type 的进一步的充血：
- 上面的例子中的枚举类型包含了行为，因此已经算作充血模型了，但是还可以为其进一步充血；
- 例如有些场景下，只是要对枚举值做个简单的计算获得某种 flag 标记，那就没必要把计算逻辑抽象成 NotifyMechanismInterface 那样的接口，杀鸡用了牛刀；
- 这时就可以在枚举类型中增加 static function 封装简单的计算逻辑；
策略实现的进一步抽象：
- 当各个策略实现（byEmail bySms byWechat）存在共性部分、重复逻辑时，可以将其抽取成一个抽象父类；
- 然后就像前一章节——业务模板 Pattern of NestedBusinessTemplate 那样，在各个子类之间实现优雅的逻辑分离和复用。

利用“充血枚举类型”消除if/else

无处不在的 if else 牛皮癣

猜你喜欢

热点阅读