The Nest

It is a good day to live. It is a good day to die.

重构：消除switch

| Comments

重构

这几天总结一下之前学习重构过程中比较令我印象深刻的一步。

曾经对面向对象的理解是“像现实世界一样编写程序”，面向过程则是规规矩矩的机器思维的灵活演变。前不久在《重构》里经历前后page穿针走线的几小口啃食后，发现原来面向对象需要have its own fashion.说“面向对象”是一种“思想”，是有其根基的。

而其中比较典型的就是去除switch的过程——

“面向对象程序的一个最明显的特征是：少用switch（或case）语句”。归根结底，switch的存在是为了根据判定值的不同给出不同的动作，如果从面向过程语言的最初目的分析，其存在的初衷多数是为了避免过多的if&else语句。然而在面向对象的语言当中，我们往往用不同的对象来封装旗下的动作（function）。因此switch作为“动作指示灯”的一部分作用就显得不合时宜了——既然我们可以将动作（function）封装到各自所属的类中，在程序里使用switch来“引路”，与面向对象的思想大相径庭。

Switch must GO.

《Refactor》给出的是公司职员薪资的例子，并以此基础完成了消除switch的史诗。个人觉得书中的例子举得很清晰明确且贴近现实，建议有机会能够亲自按《Refactor》列举的过程走一遍。这里试着借助盒子和小球来重现重构的过程：

有红色和黄色两种盒子，各有一个按钮；按动红盒的按钮红盒会弹出一个红球，黄色同理。我们的function就是根据自己想要的颜色来按按钮，于是原始的switch实现是这样的：

1
2
3
4
5
6
7
8
9
10
11

public void getBall(int color) {
    switch(color) {
        case RED:
            GIVE THE RED BALL;
            break;
        case YELLOW:
            GIVE THE YELLOW BALL;
            break;
        ......
    }
}

第一步：取代类型码

“你有一个不可变的类型码，它会影响类的行为——以子类取代这个类型码” “你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它——以状态对象取代类型码”

什么叫影响类的行为？在这里的例子中就是颜色（类型码）会对弹出什么球（行为）有影响。怎么判断能不能使用继承呢？这要看现实条件了。在这里的例子中，如果盒子的需要有这样一个功能，比如有一天人们需要再添加一种蓝盒弹蓝球，他们如果需要现有的的盒子具有“一键变身”功能（如让某个红盒一键变蓝盒），那么这时利用继承恐怕就不合适了，因为红&蓝在此时必然是继承自同一父类的2个子类，各自有不同的fuction。我们无法让RedBox类在代码中一下子变成BlueBox类。对应的，如果人们不用这么强大的盒子功能，使用简单的继承就好~

Replace Type Code With Subclasses

自然的，父类就是Box，而我们的RedBox,YellowBox继承自它。由于盒子均要实现弹球的动作，我们可以在父类中定义抽象函数，让子类各自实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

//父类Box
class Box {
    static final int RED = 1;
    static final int YELLOW = 2;

    abstract void getBall();
    abstract int getType();

    static Box create(int type) {
        switch (type) {
            case RED:
                return new RedBox();
            case YELLOW:
                return new YellowBox();
            default:
                throw new IllegalArgumentExcption("Incorrect tpye code value");
        }
    }
}

//子类RedBox,YellowBox同
class RedBox extends Box {
    public void getBall() {
        GIVE THE RED BALL;
    }

    int getType() {
        return Box.RED;
    }
}

class YellowBox extends Box....

“这里只有一处用到的switch语句，并且只用于决定创建何种对象，这样的switch语句是可以接受的”。

Replace Type Code with State/Strategy

当类型码因为一些原因不能通过继承消除时，我们往往需要考虑通过State/Strategy模式完成取代。

“我们需要声明一个状态类，把它声明为一个抽象类，并提供一个抽象函数，用以返回类型码”。由于类型码的改变不能借由继承来完成，也就是说我们构造RedBox、YellowBox的判断不能再放在Box当中，这就是我们为什么要新建一个BoxType来实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

//新建的BoxType类用以存储类型码
abstract class BoxType {
    final static int RED = 1;
  final static int YELLOW = 2;
  
  abstract int getTypeCode();
  
  static BoxType newType(int code) {
      switch(code) {
        case RED:
            return new RedBox();
        case YELLOW:
            return new YellowBox();
        default:
            throw new IllegalArgumentException("Incorrect Box Code");
      }
  }
}

//子类RedBox继承自BoxType，Yellow同
class RedBox() extends BoxType {
    int getTypeCode() {
        return BoxType.RED;
    }
}

class YellowBox() extends BoxType...

//Box类，原本类型码int值_type用新建的BoxType类_type替代
class Box {
    private BoxType _type;

    void setType(int code) {
        _type = BoxType.newType(code);
    }

    //BoxType中的抽象方法，将在被继承的RedBox，YellowBox中被各自实现
    int getType() {
       return _type.getTypeCode();
    }

    //根据BoxType中的类型码给出对应的球
    public void getBall() {
        switch(getType()) {
        case BoxType.RED:
            GIVE THE RED BALL;
            break;
        case BoxType.YELLOW:
            GIVE THE YELLOW BALL;
            break;
        default:
            throw new RuntimeException("Incorrect BoxType");
        }
    }
}

什么什么，说是要消除switch结果现在蹦出了两个？！看管别急，因为这一步的主要目的是将类型码从Box中消除（事实上转移到了新建的BoxType类当中），接下来的步骤里将会对switch进行清理。

第二步：清理条件表达式switch

“你手上有个条件表达式，它根据对象类型的不同选择不同的行为——将这个条件表达式的每个分支放进一个子类内的复写函数中，然后将原始函数声明为抽象函数”

说的再具体直白一些，那就是将getBall的动作设法交给各自的Box来实现，如此原本保有条件表达式（switch）的父类（BoxType）不再实现具体的动作，能力架空之后自然将其声明为抽象函数“以示职能”，条件表达式也自然而然消失不见。

这一步主要是针对行为选择性的条件表达式进行清理，所以第一步中Replace Type Code With Subclasses里父类中的switch人畜无害，我们自然要对State/Strategy法的历史遗留问题进行开刀：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

abstract class BoxType {
    final static int RED = 1;
  final static int YELLOW = 2;
  
  abstract int getTypeCode();
  
  static BoxType newType(int code) {
      ......
  }
  
  abstract void getBall(Box box);
}

class RedBox() extends BoxType {
    int getTypeCode() {
        return BoxType.RED;
    }

    void getBall(Box box) {
        GIVE THE RED BALL;
    }
}

class YellowBox() extends BoxType...

那么Box类此时还留之何用呢？事实上此时Box原本的职能基本都交给了BoxType，对不同颜色Box的新建工作也基本不需要再经由它（用到RedBox只需要实例化一个RedBox就好）。不过作为所有Box对象的原型，Box类中可以储存一些必要的、各类型盒子都会用到的共同动作——比如GIVE THE BALL，盒子内部的抓球动作也许就是所有盒子都要进行的共同动作。此时我们只要在Box中实现一次，由于abstract void getBall(Box box)参数中传入了Box，在红盒黄盒实现的过程中我们只要直接调用就OK了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class Box {
    private BoxType _type;

    //此时实例化某种Box已经不需要借由Box类，此时setType方法可以去除了
    //void setType(int code);

    int getType() {
       return _type.getTypeCode();
    }

    public void grab() {
        THE ACTION OF GRAB;
    }
}

abstract class BoxType {
    final static int RED = 1;
  final static int YELLOW = 2;
  
  abstract int getTypeCode();
  abstract void getBall(Box box);
  
  //同理BoxType类里的newType()也可以去除，其下的switch也被清理
  //static BoxType newType(int code)
}

class RedBox() extends BoxType {
    int getTypeCode() {...}

    //GIVE THE RED BALL的具体分步实现
    void getBall(Box box) {
        box.grab();
        box.XXX();
        .......
    }
}

至此，Replace Type Code with State/Strategy中的switch便被我们清理完成。

关于原书《重构》中这一过程的实现案例，即Employee例子的代码实现，上传到了 http://download.csdn.net/detail/u011185952/9501796 供大家小小对比一下。其实关于重构的学习是一个过程问题，最好的学习方法是从重构前到重构后亲自实现一遍，细细体会个中步骤的目的与结果。

Comments