以下内容来自<<重构 改善既有代码的设计>>
一、什么是重构
所谓重构(Refactoring)是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。从本质上说，重构就是在代码写好之后改进它的设计。
二、什么样的代码需要重构
哪些代码需要重构呢？<<重构 改善既有代码的设计>>中列出了一个“坏味道条款”，当代码中出现了这些坏味道时，应该考虑重构。
代码的坏味道
1.用多态代替价格条件逻辑代码
经过前一阶段的重构，我们注意到switch语句：在Rental类中使用了Movie类的属性，这不是什么好主意，如果不得不使用，我们应该尽量在自己对象上使用自己的数据，而不应该过多的使用别人的数据，如：
public class Rental... public double getCharge()
{ double result
= 0; switch(getMovie().getPriceCode())
{ //各种影片的价格不同 case Movie.REGULAR: result
+= 2; if(getDaysRented()>2) result
+= (getDaysRented()-2)*1.5; break; case Movie.NEW_RELEASE: result
+= getDaysRented()*3; break; case Movie.CHILDRENS: result
+= 1.5; if(getDaysRented()>3) result
+= (getDaysRented()-3)*1.5; break; } return result; } |
这暗示我们应该先把getCharge()移动到Movie中：
public class Movie ... public double getCharge(int daysRented) { double result = 0; switch(getPriceCode()) { //各种影片的价格不同 case Movie.REGULAR: result += 2; if(daysRented>2) result += (daysRented-2)*1.5; break; case Movie.NEW_RELEASE: result += daysRented*3; break; case Movie.CHILDRENS: result += 1.5; if(daysRented>3) result += (daysRented-3)*1.5; break; } return result; } }
为了能够让程序正常运行，我们需要将租期长度作为参数传递进去。然而，租期长度又来自于Rental类，这里你就可能产生疑问了。既然switch语句会影响两个类中的数据，我们为什么要把getCharge()从Rental(此方法在Rental中表示：将影片类型传递到Rental对象)类中移到Movie(将租期长度传递到Movie对象)类中呢？因为本系统可能发生的变化是影片类型的改变，这种变化是不稳定的。我希望引起的连锁反应是最小的，所以选择在Movie中计算费用。相应的，应该改变Rental类：
public class Rental ... public double getCharge() { return movie.getCharge(daysRented); }
移动了getCharge()方法后，我以同样的手法处理点数(积分)的计算，以保证把将会因影片类型改变而改变的代码都放入Movie类中。Rental类就由：
public class Rental ... public int getFrequentRenterPoints() { if((getMovie().getPriceCode()==Movie.NEW_RELEASE)&& getDaysRented()>1) return 2; else return 1; } }
变成：
public class Rental ... public int getFrequentRenterPoints() { return movie.getFrequentRenterPoints(daysRented); } }
相应的Movie类中新增加一方法：
public class Movie... public int getFrequentRenterPoints(int daysRented) { if(getPriceCode()==Movie.NEW_RELEASE && daysRented>1) return 2; else return 1; } }
2.终于说到继承了
我们有不同种类型的影片，它们以不同的类型回答相同的问题(影片类型的不同，都是为了计算出租赁的费用)。所以，我们想到了可以建立3个子类，每个子类都有自己的计费方式，它们计算各自的费用，它们的关系如下(以继承机制表现不同影片)：
这样，我们就可以用多态取代switch语句了。但是遗憾的是，我们不能这么干，因为一部影片可以在自己的生命周期内修改自己的类型，一个对象却不能在生命周期类修改自己所属的类。但是，我们仍有解决的办法，那就是运用State模式(或译：状态模式)，运用它以后，我们的类关系应该如下(运动State模式表现不同的影片)：
这里增加了一个中间层，就可以在Price对象进行继承动作了，我们可以按照我们的需求随时改变Price(价格)。
如果你很熟悉设计模式，你可能会问：这是一个State还是一个strategy？答案取决于Price类究竟代表计费方式还是代表影片的某个状态。对于模式的选择反映出你对结构的想法，这里把它视为影片的某种状态。如果未来你觉得strategy能更好的说明你的意图，你可以再改造它以形成strategy。
接下来，我将运用3个重构准则。首先运用了Replace Type Code with State/strategy，将与影片类型相互依赖的行为(Type Code bahavior)移动到State模式内。然后运用Move Method将switch语句移到了Price类中，最后运用Replace Conditional with Polymorphism去掉switch语句。
首先我使用Replace Type Code with State/strategy。第一步将与类型相依赖的属性使用Self Encapsulate Field以确保任何时候都可以通过get和set方法获得这些属性。这样做是因为其它类中的很多代码都已经使用了这些属性，大多数方法也通过get方法来获取这些属性。当然，构造方法仍然可以直接使用属性值。
public class Movie ... private String title; //片名 private int priceCode; //价格代号 //getter and setter }
构造方法中我们可以用setter代替，如：
public class Movie ... private String title; //片名 private int priceCode; //价格代号 //getter and setter public Movie(String title, int priceCode) { this.title = title; setPriceCode(priceCode); } }
现在我加入新的类，在Price 类中提供抽象方法getPriceCode(与类型相依赖的行为)，子类中来实现这个抽象方法：
public abstract class Price { abstract int getPriceCode(); } public class ChildrensPrice extends Price { @Override int getPriceCode() { return Movie.CHILDRENS; } } public class NewReleasePrice extends Price { @Override int getPriceCode() { return Movie.NEW_RELEASE; } } public class RegularPrice extends Price { @Override int getPriceCode() { return Movie.REGULAR; } }
先在我要修改Movie的访问方法(get和set方法)，下面是重构前的样子：
private int priceCode; //价格代号 public int getPriceCode() { return priceCode; } public void setPriceCode(int priceCode) { this.priceCode = priceCode; }
这意味着，我必须在Movie类中保存一个Price对象而不再是一个priceCode变量，此外我还要修改访问方法：
public class Movie ... private Price price; public int getPriceCode() { return priceCode; } public void setPriceCode(int arg) { switch(arg) { //各种影片的价格不同 case REGULAR: price = new RegularPrice(); break; case NEW_RELEASE: price = new NewReleasePrice(); break; case Movie.CHILDRENS: price = new ChildrensPrice(); break; default: throw new IllegalArgumentException("Incorrect Price Code"); } }
第二步，我将对getCharge()运用Move Method，重构之前如下：
public class Movie ... public double getCharge(int daysRented) { double result = 0; switch(getPriceCode()) { //各种影片的价格不同 case Movie.REGULAR: result += 2; if(daysRented>2) result += (daysRented-2)*1.5; break; case Movie.NEW_RELEASE: result += daysRented*3; break; case Movie.CHILDRENS: result += 1.5; if(daysRented>3) result += (daysRented-3)*1.5; break; } return result; }
重构之后：
public class Movie ... public double getCharge(int daysRented) { return price.getCharge(daysRented); } public abstract class Price ... public double getCharge(int daysRented) { double result = 0; switch(getPriceCode()) { //各种影片的价格不同 case Movie.REGULAR: result += 2; if(daysRented>2) result += (daysRented-2)*1.5; break; case Movie.NEW_RELEASE: result += daysRented*3; break; case Movie.CHILDRENS: result += 1.5; if(daysRented>3) result += (daysRented-3)*1.5; break; } return result; } }
第3步，我将运用Replace Conditional with Polymorphism，将switch的每一个分支用于一个子类的覆写方法，重构后如下：
public abstract class Price { abstract double getCharge(int daysRented); } public class RegularPrice extends Price { public double getCharge(int daysRented) { double result = 2; if(daysRented>2) result += (daysRented-2)*1.5; return result; } } public class NewReleasePrice extends Price { @Override public double getCharge(int daysRented) { return daysRented*3; } } public class ChildrensPrice extends Price { @Override public double getCharge(int daysRented) { double result = 1.5; if(daysRented>3) result += (daysRented-3)*1.5; return result; } }
最后，在对象点数(积分)的计算采用同样的方法重构，这里不再累赘叙述。这里需要注意的是普通片和儿童片的积分点数是1，新片的积分点数是2，重构的方法看下面的UML图就容易理解了：
引入State模式花费了我们不少功夫，这样做是否值得呢？如果我要修改与任何与价格有关的行为，增加一个新的价格标准，或者其它有关价格的行为，我都将很容易的对系统进行修改，而这个程序的其它部分并不知道我运用了State模式。由于目前程序中的行为太少，所以我们修改起来很容易，当在一个大的系统中，比如与价格相关的行为有十多个，修改的难度与这个相比将会有很大区别。
3.结语
这是一个简单的实例，我希望它能够让你对重构有一点感觉。实例中我使用了几个重构准则：Extract Method，Move Method和Replace Conditional with Polymorpbism。所有这些重构行为的目的都是为了是责任分配更合理，代码维护更容易。它将与结构化的编程方式有很大区别，尽管很多人习惯后者。不过只要你一习惯重构后的风格，你就很难在回到过去了，因为结构化的编程风格已经不能满足你的需求了。
这个实例给你上的最重要一课：重构的节奏，测试，小修改，测试，小修改，测试，小修改…这是这样的节奏让重构既快速又安全。如果你能跟上这个节奏，你现在应该对重构有一个基本了解了，后面我们将了解一点背景，原理和理论，当然只是一点点。
9、 基本类型偏执（Primitive Obsession）
10、switch 惊悚现身（Switch Statements）
11、平行继承体系（Parallel Inheritance Hierarchies）
13、夸夸其谈未来性（Speculative Generality）
17、狎昵关系 （Inappropriate Intimacy）
《重构-改善既有代码的设计》读书笔记
|
坏味道 |
特征 |
情况及处理方式 |
目标 |
|
|
重复代码 |
1.重复的表达式 |
同一个类的两个函数有相同表达式 |
重复代码提取为方法 |
相同表达式只在一个类的一个方法出现，供其他方法调用 |
|
兄弟类含有相同表达式 |
重复代码提取为方法 |
|||
|
不相干类含有相同代码 |
提取为独立类供调用 |
|||
|
过长函数 |
1.代码前面有注释 |
|
提取方法 |
每个方法只做一件事，方法要定义完善、命名准确 |
|
过大的类 |
1.一个类中有太多实例变量 |
部分字段之间相关性高 |
相关的字段和方法提取为类 |
每个类负责一组具有内在的相互关联的任务 |
|
某些字段和方法只被某些实例用到 |
这些字段和方法移到子类中 |
|||
|
过长参数列 |
1.参数列过长 |
方法可以通过其他方式获取该参数 |
让参数接受者自行获取该参数 |
只需要传给函数足够的、让其可以从中获取自己需要的东西就行了 |
|
同一对象的若干属性作为参数 |
在不使依赖恶化的情况下，使用整个对象作为参数 |
|||
|
被调用函数使用了另一个对象的很多属性 |
将方法移动到该对象中 |
|||
|
某些数据缺乏归属对象 |
首先创建对象 |
|||
|
发散式变化 |
一个类受多种变化的影响 |
类经常因为不同的原因在不同的方向上发生变化 |
将特定原因造成的所有变化提取为一个新类 |
针对某一外界变化的所有修改，只应发生在单一类中，而这个类中所有的内容都应反映此变化 |
|
散弹式修改 |
一种变化引发多个类的修改 |
某种变化需要在许多不同的类中做出小修改 |
把所有需要修改的代码放进同一个类中 |
针对某一外界变化的所有修改，只应发生在单一类中，而这个类中所有的内容都应反映此变化 |
|
依恋情结 |
一个函数使用其他类属性比使用自身类属性还要多 |
某个函数从另一个对象调用了几乎半打的取值函数 |
将依恋代码提取为单独方法，移动到另一对象 |
将数据和对数据的操作行为包装在一起 |
|
数据泥团 |
同时使用的相关数据并未以类的方式组织 |
|
先将字段提取为类，再缩减函数签名中的参数 |
总是绑在一起的数据应该拥有属于它们自己的对象 |
|
基本类型偏执 |
过多使用基本类型 |
总是被放在一起的基本类型字段 |
提取类 |
将单独存在的数据值转换为对象 |
|
参数列中有基本类型 |
提取参数对象 |
|||
|
数组中容纳了不同的对象，需要从数组中挑选数据 |
用对象取代数组 |
|||
|
基本数据是类型码 |
使用类替换类型码 |
|||
|
带条件表达式的类型码 |
使用继承类替换类型码 |
|||
|
Switch语句 |
相同的switch、case语句散布于不同地方 |
根据类型码进行选择的switch |
使用多态替代switch |
避免到处做相同的修改 |
|
单一函数中有switch |
使用显式的方法取代参数 |
|||
|
平行继承体系 |
1.为某个类增加子类时，必须为另一个类增加子类 |
|
一个继承体系中的实例引用另一个继承体系中的实例，然后迁移成员 |
避免到处做相同的修改 |
|
冗赘类 |
类无所事事 |
父类和子类无太大差别 |
将它们合为一体 |
|
|
某个类没有做太多事情 |
将这个类所有成员移到另一个类中，删除它 |
|||
|
夸夸其谈未来性 |
|
某个抽象类没有太大作用 |
将父子类合并 |
|
|
不必要的委托 |
将这个类所有成员移到另一个类中，删除它 |
|||
|
函数的某些参数未用上 |
移除参数 |
|||
|
函数名称带有多余的抽象意味 |
重命名函数名 |
|||
|
函数只被测试方法调用 |
连同测试代码一并删除 |
|||
|
令人迷惑的暂时字段 |
1.某个实例字段仅为某种情况而设 |
|
提取单独的类，封装相关代码 |
|
|
过度耦合的消息链 |
一长串的getThis或临时变量 |
客户类通过一个委托类来取得另一个对象 |
隐藏委托 |
消除耦合 |
|
中间人 |
某个类接口有大量的函数都委托给其他类，过度使用委托 |
有一半的函数 |
移除中间人 |
|
|
少数几个函数 |
直接调用 |
|||
|
中间人还有其他行为 |
让委托类继承受托类 |
|||
|
狎昵关系 |
某个类需要了解另一个类的私有成员 |
子类过分了解超类 |
将继承改为委托，把子类从继承体系移出 |
封装 |
|
类之间双向关联 |
去掉不必要的关联 |
|||
|
类之间有共同点 |
提取新类 |
|||
|
异曲同工的类 |
两个函数做同一件事，但是签名不同 |
|
合并 |
|
|
不完美的类库 |
类库函数构造的不够好，又不能修改它们 |
想修改一两个函数 |
在调用类增加函数 |
|
|
想添加一大堆额外行为 |
使用子类或包装类 |
|||
|
幼稚的数据类 |
某个类除了字段，就是字段访问器、设置器 |
|
1.用访问器取代public字段 |
封装 |
|
被拒绝的馈赠 |
派生类仅使用了基类很少一部分成员函数 |
子类拒绝继承超类接口 |
使用委托替代继承 |
|
|
过多的注释 |
一段代码有着长长的注释 |
|
消除各种坏味道 |
|
18、异曲同工的类 （Alternative Classes with Different Interfaces）