軟件開發-重構(2)

　　return result;

　　}

　　classAccountType...

　　double overdraftCharge(Account account){

　　if (isPremium()){

　　double result = 10;

　　if (account.getDaysOverdrawn()> 7)

　　result += (account.getDaysOverdrawn()- 7)* 0.85;

　　return result;

　　}

　　else return account.getDaysOverdrawn()* 1.75;

　　}

　　分解類(Extract Class)

　　類的職責的劃分不容易在初次設計時就準確把握，所以在編碼時重構是必要的。職責定位不清!——典型特征是擁有太多的成員變量;而在這里面最重要的就是職責要單一，屬性和方法是否合適的類中。如果不是就需要考慮分解或合并，擴展類的功能，或者抽象相應的接口。面向對象的設計原則如下：

　　1.單一職責原則(SRP)-就一個類而言，應該僅有一個引起它變化的原因

　　類的職責要單一，類里面的方法只做類的職責范圍里面的事情。MVC即是一種粗粒度的職責話費，模型類重點是提供數據，控制類重點是處理業務邏輯，而V視圖類則是關注數據獲取后的呈現。

　　數據和數據操作可以考慮分解，如形成專門的DTO數據傳輸對象類。界面類和界面數據提供類也可以考慮分離，如形成專門的Facade層專門負責數據的準備和形成。界面層不應該有太多的數據處理操作。

　　當發現一個大的類里面的屬性和方法存在明細的分組特性的時候，而且分組直接松散耦合，需要考慮分解為多個類。

　　引入方法對象來取代方法，當發現一個方法只用到該類里面的幾個關鍵屬性，方法和類里面其它的方法交互很少，輸出單一。由于該方法和這幾個屬性內聚性很強而和該類其它部分松耦合，因此可以考慮將方法和這部分屬性移出形成一個單獨的方法對象。

　　胖接口也是違反職責單一，胖接口會導致所有實現接口的類都Override所有的接口方法，而有些接口方法往往是子類并不需要的。因此對于胖接口仍然要從職責的角度對接口進行拆分。

　　2.開放——封閉原則(OCP)-對擴展開放，對修改封閉

　　當發生變化時，只需要添加新的代碼，而不必改動已經正常運行的代碼：軟件人的夢想!而要達到這個目的，關鍵是要能夠較為準確的預測業務變化會導致的可能會發送變化的模塊或代碼。

　　3.Liskov替換原則(LSP)

　　子類型必須能夠替換掉他們的基類型。正是子類型的可替換性，才使得使用基類類型的軟件無須修改就可以擴展。案例參考正方形駁論。矩形的合理假設：長、寬可以獨立變化;而正方形的合理假設：長、寬始終相等。因此正方形并不能從矩形繼承。

　　4.依賴倒置原則(DIP)-高層模塊不應該依賴于低層模塊;抽象不應該依賴于細節。

　　依賴倒置原則的重點是高層模塊類不要去依賴底層模塊的類，而應該去依賴接口，特別是當我們預見到底層模塊的類本身可能會擴展和變化的時候。這樣在變化的時候最大的好處就是高層類和接口不用變化。

　　類是否考慮抽象為接口，一方面是根據LSP原則進行重構，一方面是需要觀察我們建立的類，是否有多個類本身存在相同的行為或方法，如果存在則需要考慮抽象接口。

原文轉自：http://kb.cnblogs.com/page/68471/