重构：消除switch

重构

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

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

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

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

Switch must GO.

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

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

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继承自它。由于盒子均要实现弹球的动作，我们可以在父类中定义抽象函数，让子类各自实现：

//父类Box
abstract 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: