代码重构

面试落下好多节课，现在重新捡起来。
P.S. 到了HR面，好开心OVO 2015／04／23 14：41

首先是重构的概念：

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

.摘自<重构 改善既有代码的设计>

也就是说重构是为了使得程序变得容易理解。当然重构得建立在不影响程序正常运行结果

每当我要进行重构的时候，第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境
.摘自<重构 改善既有代码的设计>

---

好的 现在开始将常见的重构情况（22种代码味道，这里的味道是smelly）整理成下表：

类内味道

味道名称	关键词	处理方法	详情	备注
过长函数	代码行 、方法名过长	提炼函数	将函数切分成一个个小函数（从复用的角度）
		以查询替代临时变量	`比如：int sum = a + b; —>getSum(a,b);`	说实在的，这个方法也只有在频繁使用类似a+b的公式计算的时候才有所作为，而且函数调用 似乎会折损点效率，毕竟压栈弹栈
		引入参数对象	对于参数列表中大量的参数，将这些参数封装到对象里面	一般来说这个方法比较适合这些参数有一定联系的，比如username password address…
		以函数对象取代函数	新建一个类，将庞大的函数切分成多个函数作为新类的方法，其中局部变量作为类的字段	原因：如果一个函数的局部变量泛滥的话，对于提炼函数来说，有点困难，因为每一个子函数都需要传入局部变量。而新建类其中局部变量成为成员变量，自然可以自由访问，无需显式传值
		分解条件表达式	提炼条件表达式，将条件表达式（较长的判断以及方法体）封装成一个个函数。	原因：由于if（或switch）情况过多，条件判断复杂，方法体过长等导致的函数过长，可读性差（一般需要在每个方法体的开头都必须写上注释）. 注意函数命名时，需做到一目了然
过大类	功能过多，实例变量过多（违反单一职责原则）	提炼子类	太多实例变量或太多代码，分离出小类，与原来的类形成关联关系。
		提炼接口	确认客户端如何使用？？？	这个我还是有点不解，按道理提炼出来的接口是需要实现的，也就是说原类里面还是需要有相关的函数，难道是提炼函数的别名？？？
		复制”被监视数据”	把数据和行为分别移到一个独立的领域对象，但需要保留一些重复（重叠）数据。	最常用的地方就是：观察者模式。 传统的GUI集合数据处理 —> MVC Model只做数据处理，View只做界面更新，而Control连接这两个，每当界面有事件触发，发送给Model，每当Model修改数据，通知View界面更新
过长参数列	如题	引入参数对象	见上文
		以函数取代参数	向已有对象发出一条请求就可以取代一个参数	也就是说在参数列表引入这个参数是多余的，毕竟可以直接跟已有对象拿
		保持对象完整	将来自同一个对象的一堆参数收集起来	它指的是，参数项就是同一个对象的一个个参数，比如Account : username,address,phone function store(username,address,phone)其实可以取代为store(account)
过多的注释	画蛇添足，赘肉	提炼函数	将需要注释的代码块封装到函数中去	注意函数的命名应该能简单明了的知道其功能，其实就是把注释写道函数命名去了
		函数改名	提炼过的函数还需要注释来解释其行为，说明命名不佳	–
		引入断言	将说明系统需求规格的注释，改成断言	断言 Assert， 其实就是类似与判空之类的判断语句 比如： assert（name）
夸夸其谈的未来性	超越一个时代的想法，最终因实际中无法实现而沉淀在历史的长河中	折叠继承体系	某个抽象类无多大作用，直接取消抽象类，将其子类改成类	抽象层不一定越多越好，动态联编其实会对程序的效率有所折损（但是如果考虑到灵活性和扩展性，又可以忽略这些折损，其实编程也是需要你权衡利弊，没有绝对，depend on circumstances）
		将类內联化	将俩个类合并	取消不必要的委托（关联），如果一个类跟另一个类的关系非常紧密（依恋情结？），而且另一个类跟其他类无多少交际，直接将这俩类合并。（这个也是无绝对的，万一导致过大类呢？奇怪，我们学到的方法却是自相矛盾的，类內联化–提炼子类 解决这个矛盾的方法是：中庸）
		移除参数	函数的某些参数未被使用（多余的）	–
		函数改名	函数名称带有多余的抽象涵义	–
		内联函数/移除函数	作用不大的函数，可以移除掉，或者是与其他函数合并	内联函数–提炼函数
重复代码	相似的代码结构，多处出现	提炼函数	同一个类的函数之间或者函数内部方法体内有相似的代码	–
		提炼函数／函数上移／塑造模板函数	情况为：两个互为兄弟的子类含有相同的方法	函数上移，就是将这些函数移动到父类中去（提炼函数 跟这个一样吧。。）塑造模板函数：当函数之间的结构相似，中间填充的内容不同时，可以在父类中塑造一个函数模板，让这些兄弟类的不同实现作为其填充剂
		提炼类	两个毫不相关的类含有相同的代码	将相同的代码提炼的一个新类中，让这俩个类调用其方法
异曲同工的类	相同的事情， 不同的签名	函数改名	改成相同的签名？	我只想知道 有何作用。。。
搬移函数	将某些行为移入类，直到两者的协议一致为止。	这句话的理解应该是？？？
提炼超类	提炼超类作为模板，具体变化在子类	–
Switch惊悚现身	switch语句通常会导致代码重复（不同情况的方法体结构可能相同，只是里面的细节不同）	提炼函数，搬移函数，以多态取代条件表达式，以子类取代类型码，以State/Strategy（策略模式）取代类型码	与类型码相关的函数或类

---

类间味道

---

//提炼函数：
public class Report {
    public static void report(Writer out, List machines, Robot robot) throws IOException) {
    out.write("FACTORY REPORT\n");
    Iterator line = machine.iterator();
    while (line.hasNext()) {
        Machine machine = (Machine)line.next();
        out.write("Machine " + machine.name());

        if (machine.bin() != null)
        out.write(" bin= " + machine.bin());
        out.write("\n");
    }
    out.write("\n");

    out.write("Robot");
    if (robot.location() != null) 
        out.write(" location =" + robot.location().name());
    if (robot.bin() != null)
        out.write(" bin = " + robot.bin());
    out.write("\n");
out.write ("==========\n");
  } 
}
//change to...
public static void report (PrintStream out, List machines, Robot robot) {
    reportHeader(out);
    reportMachines(out, machines);
    reportRobot(out, robot);
    reportFooter(out);
}
//以上代码摘自weiliu_china

上面将大片的代码提取成函数（这大片的代码实质上是移动到其他函数中），有何好处呢？
1，增加代码的复用性
相似的情况只需调用这些函数即可
2，便于代码维护
假设此时需要修改对Footer的report，只需修改reportFooter函数，而不是一改改多处（后面会提到霰弹式修改），便于维护

其实，良好的代码风格就是：用人不疑。"放心"的调用里面的函数而不关心里面如何实现
（因为如果干涉里面的实现，会在调用前（后）增加额外的代码，实质上是增加了自身的特殊性以及对这个函数的依赖性，如果这个函数里面的实现发生变化，有可能这边的代码也需要变化，这就是耦合。以后找到一个较好的例子再好好解释。）
比较好的例子是OSI模型。
OSI模型中 上下层之间是通过相应的接口通信的，上下层之间并不关心对方具体如何实现，他只知道对方提供的接口能实现他的功能
所以当某一层内部发生修改的时候，他的上下层不需要修改（因为我知道他会帮我做好我交付给他的事，至于他的私生活，我觉得并不影响我对他的看法）
感兴趣可以去看"迪米特法则"

//分解条件表达式：

／／塑造模板方法：
两个兄弟类之间含有相同的代码，
父类构建一个模板，让兄弟类不同的实现作为填充剂。
class A：
public void getTea() {
    //...
    //warm the water by stove
    //clean the silver tea pot
    //put the green tea
    //...
}
class B:
public void getTea() {
    //...
    //warm the water by stove
    //clean the silver tea pot
    //put the black tea
    //...
}
//change to:
class Father:
protected abstract void putTea();
...
public void getTea() {
    //...
    putTea();
    //...
}

class A（B）
分别实现独有的putTea()操作。

thanks to http://www.cnblogs.com/matchcolor/tag/%E9%87%8D%E6%9E%84/