重構_改善既有的代碼設計（一）

一、代碼塊愈小，代碼的功能就愈容易管理

二、將switch語句，提煉到獨立的函數中

三、尋找switch語句中的局部變量

四、查看局部變量在switch語句內是否被修改，沒有被修改的，能夠考慮當作參數傳入

被修改的能夠考慮，做爲獨立函數的返回值返回。返回的一個變量，能夠更名爲result，看着就知道是什麼意思。傳入的rental，能夠改成aRental，代表是一個。

注意返回值類型。

五、發現獨立函數使用了來了Rental類的信息，卻沒有使用來自Customer類的信息，

可能函數放錯地方了，將函數移到Rental中，並修改方法名爲getCharge，由於這是一個計算費用的方法，方法名要能表示功能。

六、發現原來statement方法中的thisAmount變量，接受each.getCharge（）的執行結果以後，就再也不有任何改變，因此能夠直接用each.getCharge（）代替。儘可能去除這一類臨時變量。臨時變量每每引起問題，它們會致使大量參數被傳來傳去，而其實徹底沒有這種必要。你很容易跟丟它們，尤爲在長長的函數之中更是如此。固然這麼作也需付出性能上的代價，好比本例的費用就被計算了兩次。但這很容易在Rental類中被優化。。。並且若是代碼有合理的組織和管理，優化就會有很好的效果。

七、將statement方法中的「常客積分計算」部分，抽出來，看着應該是放在Rental類中。臨時變量frequentRenterPoints，在它被使用以前，先有初始值，可是提煉出來的函數並無讀取該值，因此咱們不須要將它當作參數傳進去，只需把新函數的返回值累加上去就行。

八、去除臨時變量。臨時變量多是個問題，它們只在本身所屬的函數中有效，它們會滋長冗長而複雜的函數。在Customer類中新建一個方法getTotalCharge（），從新編寫計算過程，而後用這個方法取代totalAmount這個局部變量。臨時變量frequentRenterPoints也作一樣的處理。咱們須要把循環複製到這兩個方法中

九、這時候，用戶準備更改影片分類規則，與之相對應的費用計算方式和常客積分計劃還有待決定，如今還不宜對程序作修改。咱們必須進入費用計算和常客積分計算中，把因條件而異的代碼替換掉（這裏指的是switch語句中的case子句）

十、運用多態取代與價格相關的條件邏輯。最好不要在另外一個對象的屬性基礎上運用switch語句。若是不得不使用，也應該在對象本身的數據上使用，而不是在別人的數據上使用。如本例，switch(getMovie().getPriceCode())...暗示getCharge()應該移到Movie類裏去，須要把租期長度做爲參數傳進去。租賃長度來自Rental對象。計算費用時須要兩項數據：租期長度和影片類型。爲何選擇將租期長度傳給Movie對象，而不是將影片類型傳給Rental對象？系統可能發生的變化時加入新影片類型，若是影片類型有所變化，儘可能控制它形成的影響（保持不變），因此選擇在Movie對象內計算費用。用一樣的手法處理常客積分計算。

十一、一部影片能夠在生命週期內修改本身的分類，一個對象卻不能在生命週期內修改本身所屬的類（這句話有點抽象啊，不是很理解）。下面引入State模式與Strategy模式，以前只據說過Strategy模式，補一下State模式，並瞭解到這兩個設計模式很是類似，只是State多了狀態的改變（不知道說得對不對）。

接下來是一堆的重構。第一個例子很是精美，對重構感興趣的，均可以去看一看