像工匠一样进行重构--《Refactoring WorkBook》

 作者： 江南白衣
 
 像工匠一样进行重构, 让重构成为一门手艺.
Martin Fowler的《Refactoring》其实更适合做一本关于重构的洗脑，宣言式的书，就像Kent Beck的《XP Explain》一样薄薄的就可以了。只可惜他却非常的厚，后面的重构名录都是写给小白看的。所以我更喜欢《Refacoring WorkBook》，以一个工匠的语气（沉默寡言而实要）传授重构的手艺。

1.重构 Between Classes

   〈Design pattern〉有半数篇幅教育大家不能只靠继承，要善用组合/委托。重构里面其实也有很多事情靠把继承变成委托来解决。

  1 .1继承
     1.1.1 并行继承体系，组合爆炸
               这在以前是个头痛的问题，现在都已习惯用委托。
               另外java还有个不是很让人满意的接口机制解决并行继承。
     1.1.2  父子类的关系

                比如过于亲密，子类会乱修改父类的方法，访问父类的变量，这时候可以定义final的Template方法。

                还有拒绝的馈赠，我暂时还没有在这上面遇到问题，作者也建议如果没事就由他，如果有事，就要费劲的move method ；或者子类不继承父类，而只是组合父类。

   1 .2职责
     经过很多次重构之后，我发现，其实哪个方法应该放在哪个类其实很主观的，你每天醒来都能想到一个理由让一个方法搬一下家，所以我现在已经放弃追求一种“对”的职责分配了，看着顺眼就行。
    

  1 .3散弹式修改
     作一个修改就要改N个类时，也没什么特别好方法，就是找找看，有没有能为这个修改负责的统管全局的类。
     但现在的很多散弹式修改是分层做成的。

  1 .4库类
     OpenSource的类库，总有些时候会想要扩展
     1.如果只是一两个方法,直接在客户代码里扩展,
     2.否则自己多一个类库的子类
     3.最费劲就是引入一个新的层

    
 题外话，重构其实很依赖工具，和对全部代码的拥有度，哗一下就来个全项目的rename。当你设计库类时，你并不一定拥有使用这些库类的 客户代码了，因此一开始就要认真设计，不能依赖重构，改接口会让人K死的。

2.重构 Within Classes

2.1 大是罪
   Long Method、Large Class、Long Parameter List， 一般通过度量工具找出来，还可以自己设定一个触发器，当度量值超过某个限度时就报警。
   PMD可以实现这个功能，但度量工具我更喜欢Metrics Reload，一个IDEA的插件，给出的度量信息很全面。
   但是也切忌为了度量的数值而重构。
   Long Method当然是尝试Extract Method。
   Large Class就要把类的职能分开几个域，尝试拆出另一个Class或者SubClass。
   Long Parameter List 可以通过在方法内的变量用查询获得而不用由参数传入;
                                  或者把某些参数组成一个对象。

 

1.2 重复也是罪
    重复在30年前就被认为是不好的一样东西，表现在1.代码类似，2.代码、接口不同而作用相近。
    去除重复的方法也没什么特别，无非就是
    Extract Method(同一个类)。有差异时，通过参数化达到共用。
    Pull Up Method到父类(同一个父类)。有差异时，通过模板机制达到共用。
    Class A调用Class B   或者   Extract Class C  (两个完全无相干的类)

 

1.3 命名
   中国程序员的英文本来就差，要多参考Ofbiz、Comperie的命名， 尽快建立团队的项目字典、领域术语字典。

   也幸亏，现在在工具辅助下，代码的rename是最容易的重构。

1.4复杂条件表达式
   作者认为，即使现在Program最关注的是对象，以及对象间的关系了，但优质的内部代码依然重要，推荐《编程珠玑》和《Elements of Programing style》。

   化简复杂条件的基本有三个方法
    1.通过!(A&B)==(!A)||(!B)化简
    2.通过有意义的变量,函数代替条件表达式，比如
       boolean isMidScore = (X>1000)&&(X<3000);
    3.通过把一个if拆分开来执行，把guard clause放在前面
      比如if(A||B)
                  do();
            ->if(A)
                  do();
               if(B)
                  do();
          又可以把2、3灵活组合，比如根据2，Extract出一个isRight()函数，根据3

    isRight()
    { 
      if(A)
        return true;
      if(B)
        return true;
      return false;
    }

1.5 其他
   没用的死代码，通过IDE工具探知并移除。小心有些框架代码是不能删除的。
   Magic Number，当然是改为常量。如果Magic Number很多，可以用Map、枚举类来存放。
   除臭剂式的注释，为方法,变量改一个更适合的名字。如果注释是针对一个代码段的，可以Extract Method。当然，代码只能说明how, 不能说明why，更不能说明why not，这才是注释存在的地方。