2018-10-18 重构的那些事儿-令人厌恶的If~else switch caseif/else的恶瘤重构初体验–反射重构初体验–所谓模式重构初体验–Java8对模式设计的精简总结

原文出处: Jun.M

几天前的一次上线,脑残手抖不小心写了bug,虽然组里的老大没有说什么,但心里面很是难过。同事说我之所以写虫子是因为我讨厌if/else,这个习惯不好。的确,if/else可以帮助我们很方便的写出流程控制代码,简洁明了,这个条件做什么,那个条件做什么,说得很清楚。说真的,我从来不反对if/else,从经验上看,越复杂的业务场景下,代码写的越简单单一,通常越不容易出错。以结果为导向的现代项目管理方式,这是一种很有效实践经验。

同事说的没错,我的确很讨厌if/else。这个习惯很大程度是受Thoughtworks一位咨询师朋友影响,他经常在我耳边唠叨,写代码要干净,要简洁,要灵活多变,不要固守城规,不要动不动就if/else,switch/case。初入IT领域,我一直把这句话奉为经典。在以后的学习工作中也时刻提醒自己要让自己的代码尽可能的看起来简洁,不失灵活。不喜欢if/else并不意味着拒绝它,该使用的时候必要使用,比如函数接口入参check,处理异常分支逻辑流程等。通常能不用分支语句,我尽量不会使用,因为我觉得if/else很丑,每每看到if/else代码,总会以挑剔的眼光看待它,想想能不能重构的更好。大多数时候,关于什么好的代码,大家的意见往往分歧很大,每个人都有各自的想法,审查你代码的人可能会选择另一种实现方式,这并不能说明谁对谁错。

OO设计遵循SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)原则,使用这个原则去审视if/else,可能会发现很多问题,比如不符合单一原则,它本身就像一团浆糊,融合了各种作料,黏糊糊的很不干净;比如不符合开闭原则,每新增一种场景,就需要修改源文件增加一条分支语句,业务逻辑复杂些若有1000种场景就得有1000个分支流,这种情况下代码不仅仅恶心问题了,效率上也存在很大问题。由此可见,if/else虽然简单方便,但不恰当的使用会给编码代码带来非常痛苦的体验。针对这种恶心的if/else分支,我们当然首先想到的去重构它–在不改变代码外部功能特征的前提下对代码内部逻辑进行调整和优化,但,如何做呢?前段时间在项目中正好遇到一个恶心的if/else例子,想在这篇博客里和大家分享一下去除if/else重构的历程。

image

if/else的恶瘤

有句话说的好–好文章是改出来,同样,好的代码也肯定是重构出来的,因为没有哪个软件工程师能够拍着胸脯保证在项目之初代码设计这块,就考虑到了所有需求变化可能性的扩展。随着项目的不断成长,业务逻辑变的越来越复杂,代码也开始变的越来越多,原有的设计可能不再满足需求,那么此时必须要重构。就系统整体架构而言,重构可能需要很大的改动,可能在架构流程上需要评审;就功能内代码层次而言,这种重构在我们编码过程中随时可以进行,类似于if/else,swicth/case这种代码的重构也属于这种类型。今天我们要重构的if/else源码如下所示,针对不同的status code,CountRecoder对象会执行不同的set方法,为不同内部属性赋值。

Java

public  CountRecoder getCountRecoder(List countEntries)  {

    CountRecoder countRecoder  =  new  CountRecoder();

    for  (CountEntry countEntry  :  countEntries)  {

        if  (1  ==  countEntry.getCode())  {

            countRecoder.setCountOfFirstStage(countEntry.getCount());

        }  else  if  (2  ==  countEntry.getCode())  {

            countRecoder.setCountOfSecondStage(countEntry.getCount());

        }  else  if  (3  ==  countEntry.getCode())  {

            countRecoder.setCountOfThirdtage(countEntry.getCount());

        }  else  if  (4  ==  countEntry.getCode())  {

            countRecoder.setCountOfForthtage(countEntry.getCount());

        }  else  if  (5  ==  countEntry.getCode())  {

            countRecoder.setCountOfFirthStage(countEntry.getCount());

        }  else  if  (6  ==  countEntry.getCode())  {

            countRecoder.setCountOfSixthStage(countEntry.getCount());

        }

    }

    return  countRecoder;

}

CountRecoder对象是一个简单的Java Bean,用于保存一天之中六种状态分别对应的数据条目,提供了get和set方法。CountEntry是对应数据库中每种状态的数据条目记录,包含状态code和以及count两个字段, 我们可以使用mybatis实现数据库记录和java对象之间的转换。上面getCountRecoder的方法实现了将list转换为CountRecoder的功能。

看到这段代码,想必已经有很多人要呵呵了,像一坨啥啥啥,长得这么丑,真不知道它”爸妈”怎么想的,怎么敢”生”出来。啥都不说了,直接回炉重构吧。重构是门艺术,Martin flow曾写过一本书《重构改变代码之道》,里面详细的记录了重构的方法论,感兴趣的朋友可以阅读一下。说到重构,通常我们在重构中会遇到一个问题,那就是如何能够保证重构的代码不改变原有的外部功能特征 ?经过TDD训练的朋友应该知道答案,那就是单元测试,重构之前要写单元测试,准确的来说应该是补单元测试,毕竟TDD的核心理念是测试驱动开发。对于今天博客中分享的例子,因为代码逻辑比较简单,所以偷了懒,省却了单元测试的历程。

重构初体验–反射

要重构上面的代码,对设计模式精通的人可以立马可以看出来这是使用策略模式/状态模式的绝佳场景,将策略模式稍微变换,工厂模式应该也是ok的,当然也有些人会选择使用反射。对于这些方法,这里不一一列出,主要想讲一下使用反射和工厂模式如何解决消除if/else问题,那先说反射吧,代码如下所示:

Java

private  static  Map methodsMap  =  new  HashMap();

static  {

    methodsMap.put(1,  "setCountOfFirstStage");

    methodsMap.put(2,  "setCountOfSecondStage");

    methodsMap.put(3,  "setCountOfThirdtage");

    methodsMap.put(4,  "setCountOfForthtage");

    methodsMap.put(5,  "setCountOfFirthStage");

    methodsMap.put(6,  "setCountOfSixthStage");

}

public  CountRecoder getCountRecoderByReflect(List countEntries)  {

    CountRecoder countRecoder  =  new  CountRecoder();

    countEntries.stream().forEach(countEntry  ->  fillCount(countRecoder,  countEntry));

    return  countRecoder;

}

private  void  fillCount(CountRecoder shippingOrderCountDto,  CountEntry countEntry)  {

    String  name  =  methodsMap.get(countEntry.getCode());

    try  {

        Method declaredMethod  =  CountRecoder.class.getMethod(name,  Integer.class);

        declaredMethod.invoke(shippingOrderCountDto,  countEntry.getCount());

    }  catch  (Exception  e)  {

        System.out.println(e);

    }

}

重构初体验–所谓模式

使用反射去掉if/else的原理很简单,使用HashMap建立状态码和需要调用的方法的方法名之间的映射关系,对于每个CountEntry,首先取出状态码,然后根据状态码获得相应的要调用方法的方法名,然后使用java的反射机制就可以实现对应方法的调用了。本例中使用反射的确可以帮助我们完美的去掉if/else的身影,但是,众所周知,反射效率很低,在高并发的条件下,反射绝对不是一个良好的选择。除去反射这种方法,能想到的就剩下使用策略模式或者与其类似的状态模式,以及工厂模式了,我们以工厂模式为例,经典的架构UML架构图通常由三个组成要素:

  1. 抽象产品角色:通常是一个抽象类或者接口,里面定义了抽象方法
  2. 具体产品角色:具体产品的实现类,继承或是实现抽象策略类,通常由一个或多个组成类组成。
  3. 工厂角色:持有抽象产品类的引用,负责动态运行时产品的选择和构建

策略模式的架构图和工厂模式非常类似,不过在策略模式里执行的对象不叫产品,叫策略。在本例中,这里的产品是虚拟产品,它是服务类性质的接口或者实现。Ok,按照工厂模式的思路重构我们的代码,我们首先定义一个抽象产品接口FillCountService,里面定义产品的行为方法fillCount,代码如下所示:

Java

public  interface  FillCountService  {

    void  fillCount(CountRecoder countRecoder,  int  count);

}

接着我们需要分别实现这六种服务类型的产品,在每种产品中封装不同的服务算法,具体的代码如下所示:

Java

class  FirstStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfFirstStage(count);

    }

}

class  SecondStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfSecondStage(count);

    }

}

class  ThirdStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfThirdtage(count);

    }

}

class  ForthStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfForthtage(count);

    }

}

class  FirthStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfFirthStage(count);

    }

}

class  SixthStageService  implements  FillCountService  {

    @Override

    public  void  fillCount(CountRecoder countRecoder,  int  count)  {

        countRecoder.setCountOfSixthStage(count);

    }

}

紧接着,我们需要是实现工厂角色,在工厂内需要实现产品的动态选择算法,使用HashMap维护状态code和具体产品的对象之间的映射关系,就可以非常容易的实现这一点,具体代码如下所示:

Java

public  class  FillCountServieFactory  {

    private  static  Map fillCountServiceMap  =  new  HashMap();

    static  {

        fillCountServiceMap.put(1,  new  FirstStageService());

        fillCountServiceMap.put(2,  new  SecondStageService());

        fillCountServiceMap.put(3,  new  ThirdStageService());

        fillCountServiceMap.put(4,  new  ForthStageService());

        fillCountServiceMap.put(5,  new  FirthStageService());

        fillCountServiceMap.put(6,  new  SixthStageService());

    }

    public  static  FillCountService getFillCountStrategy(int  statusCode)  {

        return  fillCountServiceMap.get(statusCode);

    }

}

客户端在具体使用的时候就变的很简单,那getCountRecoder方法就可以用下面的代码实现:

Java

public  CountRecoder getCountRecoder(List countEntries)  {

    CountRecoder countRecoder  =  new  CountRecoder();

    countEntries.stream().forEach(countEntry  ->

            FillCountServieFactory.getFillCountStrategy(countEntry.getCode())

                    .fillCount(countRecoder,  countEntry.getCount()));

    return  countRecoder;

}

重构初体验–Java8对模式设计的精简

和反射一样使用设计模式也同样完美的去除了if/else,但是不得不引入大量的具体服务实现类,同时程序中出现大量的模板代码,使得我们程序看起来很不干净,幸好Java 8之后引入了Functional Interface,我们可以使用lambda表达式来去除这些模板代码。将一个接口变为Functional interface,可以通过在接口上添加FunctionalInterface注解实现,代码如下所示:

Java

@FunctionalInterface

public  interface  FillCountService  {

    void  fillCount(CountRecoder countRecoder,  int  count);

}

那么具体的服务实现类就可以使用一个简单的lambda表达式代替,原先的FirstStageService类对象就可以使用下面的表达式代替:

Java

(countRecoder,  count)  ->  countRecoder.setCountOfFirstStage(count)

那么工厂类中的代码就可以变为:

Java

public  class  FillCountServieFactory  {

    private  static  Map fillCountServiceMap  =  new  HashMap();

    static  {

        fillCountServiceMap.put(1,  (countRecoder,  count)  ->  countRecoder.setCountOfFirstStage(count));

        fillCountServiceMap.put(2,  (countRecoder,  count)  ->  countRecoder.setCountOfSecondStage(count));

        fillCountServiceMap.put(3,  (countRecoder,  count)  ->  countRecoder.setCountOfThirdtage(count));

        fillCountServiceMap.put(4,  (countRecoder,  count)  ->  countRecoder.setCountOfForthtage(count));

        fillCountServiceMap.put(5,  (countRecoder,  count)  ->  countRecoder.setCountOfFirthStage(count));

        fillCountServiceMap.put(6,  (countRecoder,  count)  ->  countRecoder.setCountOfSixthStage(count));

    }

    public  static  FillCountService getFillCountStrategy(int  statusCode)  {

        return  fillCountServiceMap.get(statusCode);

    }

}

这样我们的代码就重构完毕了,当然了还是有些不完美,程序中的魔法数字不利于阅读理解,可以使用易读的常量标识它们,在这里就不做过多说明了。

总结

Craig Larman曾经说过软件开发最重要的设计工具不是什么技术,而是一颗在设计原则方面训练有素的头脑。重构的最终结果不一定会让代码变少,相反还有可能增加程序的复杂度和抽象性,就本例中的if/else而言,确实如此。我非常赞同我的一位朋友说的话,做技术要有追求,没错if/else可以在代码中工作的挺好,也可以很容易的被接替者所理解,但是我们可以有更好的选择,因为简单的代码也可以变得很精彩。多勤多思,也许有一天真的就可以达到Craig所说的在设计原则方面拥有训练有素的头脑,谁说不是这样呢?加油吧。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java呓语

抽象工厂模式(选择产品簇)

对简单工厂模式还不了解的可以查看下我的历史文章 简单工厂模式,简单工厂模式的核心是使用工厂实现选择创建产品实现,这应该很好理解。

11720
来自专栏一个会写诗的程序员的博客

[zz]Kotlin 和 Checked ExceptionKotlin 和 Checked Exception

最近 JetBrains 的 Kotlin 语言忽然成了热门话题。国内小编们传言说,Kotlin 取代了 Java,成为了 Android 的“钦定语言”,很多...

8920
来自专栏WindCoder

Python学习四周小结-测试题篇

自从发现网易云课堂的计算机课程系列中有Python后就报名听了下,作为新人很快被其模式所吸引了,同时发现自己之前自学时的不足,那时由于没有作业等,自己只是根据《...

26520
来自专栏程序员互动联盟

【答疑解惑】推荐给新手的Java学习资料

国际惯例,每天更新答疑解惑。网友们在群里有很多问题讨论,小编挑几个很有代表性的问题给大家叨叨几句。 一、关于Java学习资料: 昨天有网友对于Java群中资料少...

29840
来自专栏大数据钻研

如何设计优雅的类结构

注:正文中的引用是直接引用作者作者的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。 「Clean Code」这本书从这一章开始文风有些变化,...

28860
来自专栏Linyb极客之路

java代码设计的6+1大原则

1.开闭原则(Open Close Principle) 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 开放-封闭原则的意思就是说,你...

17830
来自专栏做全栈攻城狮

写好Java代码的30条经验总结

想成为一个优秀的Java程序员,有着良好的代码编写习惯是必不可少的。下面就让我们来看看代码编写的30条建议吧。

17140
来自专栏Golang语言社区

伙计们,Go 并没有那么简单

出于好奇,我最近开始接触一些 Go 的代码。我之前对它有一些了解,但是从来没有尝试去写(没有需求)。但是现在我们团队选择使用 Go 来开发一个项目,所以我觉得这...

32460
来自专栏liulun

Nim教程【三】

这是国内第一个关于Nim的系列教程 (至少我百度和必应是没有找到类似的教程) 先说废话 有人说 Golang的编译器/工具...

21690
来自专栏更流畅、简洁的软件开发方式

《你必须知道的.net》读书笔记 001——1.1 对象的旅行

    好久没看书了,上次看书的时候还是一年前了,一个偶然的机会,比较系统的看了一下OO的基础,封装、继承、多态等,当时真的是很不会,看了也是一知半解,迷迷...

20990

扫码关注云+社区

领取腾讯云代金券