### Pull Up Method(函數上移)
有些函數,在各個subclass 中產生完全相同的結果。
將該函數移至superclass。

**動機(Motivation)**
避免「行為重復」是很重要的。盡管「重復的兩個函數」也可以各自工作得很好, 但「重復」自身會成為錯誤的滋生地,此外別無價值。無論何時,只要系統之內出現重復,你就會面臨「修改其中一個卻未能修改另一個」的風險。通常,找出重復也有一定困難。
如果某個函數在各subclass 中的函數體都相同(它們很可能是通過「拷貝-粘貼」得到的),這就是最顯而易見的Pull Up Method 適用場合。當然,情況并不總是如此明顯。你也可以只管放心地重構,再看看測試程序會不會發牢騷,但這就需要對你的測試有充分的信心。我發現,觀察這些可疑(可能重復的〕函數之間的差異往往大有收獲:它們經常會向我展示那些我忘記測試的行為。
Pull Up Method 常常緊隨其他重構而被使用。也許你能找出若干個「身處不 同subclasses 內的函數」而它們又可以「通過某種形式的參數調整」而后成為相同函數。這時候,最簡單的辦法就是首先分別調整這些函數的參數,然后再將它們概括(generalize)到superclass中。當然,如果你自信足夠,也可以一次同時完成這兩個步驟。
有一種特殊情況也需要使用Pull Up Method : subclass 的函數覆寫(overrides) 了superclass 的函數,但卻仍然做相同的工作。
Pull Up Method 過程中最麻煩的一點就是:被提升的函數可能會引用「只出現于subclass 而不出現于superclass」的特性。如果被引用的是個函數,你可以將該函數也一同提升到superclass,或者在superclass 中建立一個抽象函數。在此過程中,你可能需要修改某個函數的簽名式(signature),或建立一個委托函數(delegating method)。
如果兩個函數相似但不相同,你或許可以先以Form Template Method 構造出相同的函數,然后再提升它們。
**作法(Mechanics)**
- 檢查「待提升函數」,確定它們是完全一致的(identical)。
- 如果這些函數看上去做了相同的事,但并不完全一致,可使用Substitute Algorithm 讓它們變得完全一致。
- 如果「待提升函數」的簽名式(signature)不同,將那些簽名式都修改為你想要在superclass 中使用的簽名式。
- 在superclass 中新建一個函數,將某一個「待提升函數」的代碼拷貝到其中,做適當調整,然后編譯。
- 如果你使用的是一種強型(strongly typed)語言,而「待提升函數」 又調用了一個「只出現于subclass 未出現于superclass」的函數,你可以在superclass 中為被調用函數聲明一個抽象函數。
- 如果「待提升函數」使用了 subclass 的一個值域,你可以使用Pull Up Field 將該值域也提升到superclass;或者也可以先使用 Self Encapsulate Field,然后在superclass 中把取值函數(getter)聲明為抽象函數。
- 移除一個「待提升的subclass 函數」。
- 編譯,測試。
- 逐一移除「待提升的如函數」,直到只剩下superclass 中的函數為止。每次移除之后都需要測試。
- 觀察該函數的調用者,看看是否可以將它所索求的對象型別改為superclass。
**范例:(Example)**
我以Customer「表示「顧客」,它有兩個subclass :表示「普通顧客」的RegularCustomer 和表示「貴賓」PreferredCustomer。

兩個subclass 都有一個createBill() 函數,并且代碼完全一樣:
~~~
void createBill (date Date) {
double chargeAmount = charge (lastBillDate, date);
addBill (date, charge);
}
~~~
但我不能直接把這個函數上移到superclass,因為各個subclass 的chargeFor() 函數并不相同。我必須先在superclass 中聲明chargeFor() 抽象函數:
~~~
class Customer...
abstract double chargeFor(date start, date end)
~~~
然后,我就可以將createBill() 函數從其中一個subclass 拷貝到superclass。拷貝完之后應該編譯,然后移除那個subclass 的createBill() 函數,然后編譯并測試。 隨后再移除另一個subclass 的createBill() 函數,再次編譯并測試:

- 譯序 by 侯捷
- 譯序 by 熊節
- 序言
- 前言
- 章節一 重構,第一個案例
- 起點
- 重構的第一步
- 分解并重組statement()
- 運用多態(Polymorphism)取代與價格相關的條件邏輯
- 結語
- 章節二 重構原則
- 何謂重構
- 為何重構
- 「重構」助你找到臭蟲(bugs)
- 何時重構
- 怎么對經理說?
- 重構的難題
- 重構與設計
- 重構與性能(Performance)
- 重構起源何處?
- 章節三 代碼的壞味道
- Duplicated Code(重復的代碼)
- Long Method(過長函數)
- Large Class(過大類)
- Long Parameter List(過長參數列)
- Divergent Change(發散式變化)
- Shotgun Surgery(散彈式修改)
- Feature Envy(依戀情結)
- Data Clumps(數據泥團)
- Primitive Obsession(基本型別偏執)
- Switch Statements(switch驚悚現身)
- Parallel Inheritance Hierarchies(平行繼承體系)
- Lazy Class(冗贅類)
- Speculative Generality(夸夸其談未來性)
- Temporary Field(令人迷惑的暫時值域)
- Message Chains(過度耦合的消息鏈)
- Middle Man(中間轉手人)
- Inappropriate Intimacy(狎昵關系)
- Alternative Classes with Different Interfaces(異曲同工的類)
- Incomplete Library Class(不完美的程序庫類)
- Data Class(純稚的數據類)
- Refused Bequest(被拒絕的遺贈)
- Comments(過多的注釋)
- 章節四 構筑測試體系
- 自我測試代碼的價值
- JUnit測試框架
- 添加更多測試
- 章節五 重構名錄
- 重構的記錄格式
- 尋找引用點
- 這些重構準則有多成熟
- 章節六 重新組織你的函數
- Extract Method(提煉函數)
- Inline Method(將函數內聯化)
- Inline Temp(將臨時變量內聯化)
- Replace Temp with Query(以查詢取代臨時變量)
- Introduce Explaining Variable(引入解釋性變量)
- Split Temporary Variable(剖解臨時變量)
- Remove Assignments to Parameters(移除對參數的賦值動作)
- Replace Method with Method Object(以函數對象取代函數)
- Substitute Algorithm(替換你的算法)
- 章節七 在對象之間搬移特性
- Move Method(搬移函數)
- Move Field(搬移值域)
- Extract Class(提煉類)
- Inline Class(將類內聯化)
- Hide Delegate(隱藏「委托關系」)
- Remove Middle Man(移除中間人)
- Introduce Foreign Method(引入外加函數)
- Introduce Local Extension(引入本地擴展)
- 章節八 重新組織數據
- Self Encapsulate Field(自封裝值域)
- Replace Data Value with Object(以對象取代數據值)
- Change Value to Reference(將實值對象改為引用對象)
- Replace Array with Object(以對象取代數組)
- Replace Array with Object(以對象取代數組)
- Duplicate Observed Data(復制「被監視數據」)
- Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
- Change Bidirectional Association to Unidirectional(將雙向關聯改為單向)
- Replace Magic Number with Symbolic Constant(以符號常量/字面常量取代魔法數)
- Encapsulate Field(封裝值域)
- Encapsulate Collection(封裝群集)
- Replace Record with Data Class(以數據類取代記錄)
- Replace Type Code with Class(以類取代型別碼)
- Replace Type Code with Subclasses(以子類取代型別碼)
- Replace Type Code with State/Strategy(以State/strategy 取代型別碼)
- Replace Subclass with Fields(以值域取代子類)
- 章節九 簡化條件表達式
- Decompose Conditional(分解條件式)
- Consolidate Conditional Expression(合并條件式)
- Consolidate Duplicate Conditional Fragments(合并重復的條件片段)
- Remove Control Flag(移除控制標記)
- Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
- Replace Conditional with Polymorphism(以多態取代條件式)
- Introduce Null Object(引入Null 對象)
- Introduce Assertion(引入斷言)
- 章節十一 處理概括關系
- Pull Up Field(值域上移)
- Pull Up Method(函數上移)
- Pull Up Constructor Body(構造函數本體上移)
- Push Down Method(函數下移)
- Push Down Field(值域下移)
- Extract Subclass(提煉子類)
- Extract Superclass(提煉超類)
- Extract Interface(提煉接口)
- Collapse Hierarchy(折疊繼承關系)
- Form Template Method(塑造模板函數)
- Replace Inheritance with Delegation(以委托取代繼承)
- Replace Delegation with Inheritance(以繼承取代委托)
- 章節十二 大型重構
- 這場游戲的本質
- Tease Apart Inheritance(梳理并分解繼承體系)
- Convert Procedural Design to Objects(將過程化設計轉化為對象設計)
- Separate Domain from Presentation(將領域和表述/顯示分離)
- Extract Hierarchy(提煉繼承體系)
- 章節十三 重構,復用與現實
- 現實的檢驗
- 為什么開發者不愿意重構他們的程序?
- 現實的檢驗(再論)
- 重構的資源和參考資料
- 從重構聯想到軟件復用和技術傳播
- 結語
- 參考文獻
- 章節十四 重構工具
- 使用工具進行重構
- 重構工具的技術標準(Technical Criteria )
- 重構工具的實用標準(Practical Criteria )
- 小結
- 章節十五 集成
- 參考書目