### Tease Apart Inheritance（梳理并分解繼承體系） 某個繼承體系（inheritance hierarchy ）同時承擔兩項責任。 建立兩個繼承體系，并通過委托關系（delegation）讓其中一個可以調用另一個。  **動機（Motivation）** 繼承是個好東西，它使你得以在subclass 中寫出明顯「壓縮過」（compressed）的 代碼。函數的重要性可能并不和它的大小成比例——在繼承體系之中尤然。 不過，先別急著為這個強大的工具歡呼雀躍，因為繼承也很容易被誤用，并且這種誤用還很容易在開發人員之間蔓延。今天你為了一項小小任務而加入一個小小的subclass ；明天又為同樣任務在繼承體系的另一個地方加入另一個subclass 。一個星期（或者一個月或者一年）之后，你就會發現自己身陷泥淖，而且連一根拐杖都沒有。 混亂的繼承體系是一個嚴重的問題，因為它會導致重復代碼，而后者正是程序員生涯的致命毒藥。它還會使修改變得困難，因為「特定種類」的問題的解決策略被分散到了整個繼承體系。最終，你的代碼將非常難以理解。你無法簡單地說：『這就 是我的繼承體系，它能計算結果』，而必須說：『它會計算出結果……呃，這些是 用以表現不同表格形式的subclasses ，每個subclass 又有一些subclasses 針對不同的 國家。』 要指出「某個繼承體系承擔了兩項不同的責任」并不困難：如果繼承體系中的某一特定層級上的所有classes，其subclass 名稱都以相同的形容詞開始，那么這個體系很可能就是承擔著兩項不同的責任。 **作法（Mechanics）** - 首先識別出繼承體系所承擔的不同責任，然后建立一個二維表格（或者三維乃至四維表格，如果你的繼承體系夠混亂而你的繪圖工具夠酷的話），并以坐標軸標示出不同的任務。我們將重復運用本重構，處理兩個或兩個以上的維度〔當然，每次只處理一個維度〉。 - 判斷哪一項責任更重要些，并準備將它留在當前的繼承體系中。準備將另一項責任移到另一個繼承體系中。 - 使用Extract Class 從當前的superclass 提煉出一個新class ，用以表示重要性稍低的責任，并在原superclass 中添加一個instance 變量（不是static 變量〕，用以保存新建class 的實體。 - 對應于原繼承體系中的每個subclass ，創建上述新class 的一個個subclasses 。在原繼承體系的subclasses 中，將前一步驟所添加的instance 變量初始化為新建subclass 的實體。 - 針對原繼承體系中每個subclass ，使用Move Method 將其中的行為搬移到與之對應的新建subclass 中。 - 當原繼承體系中的某個subclass 不再有任何代碼時，就將它去除。 - 重復以上步驟，直到原繼承體系中的所有subclass 都被處理過為止。觀察新繼承體系，看看是否有可能對它實施其他重構手法，例如Pull Up Method 或 Pull Up Field 。 **范例：（Example）** 讓我們來看一個混亂的繼承體系（如圖12.1）。  圖12.1 一個混亂的繼承體系 這個繼承體系之所以混亂，因為一開始Deal class 只被用來顯示單筆交易。后來，某個人突發奇想地用它來顯示一張交易表格。只需飛快建立一個ActiveDeal subclass 再加上一點點經驗，不必做太多工作就可以顯示一張表格了。哦，還要「被動交易（PassiveDeal）」表格是嗎？沒問題，再加一個subclass 就行了。 兩個月過去，表格相關代碼變得愈來愈復雜，你卻沒有一個好地方可以放它們，因為時間太緊了。咳，老戲碼！現在你將很難向系統加入新種交易，因為「交易處理邏輯」與「數據顯示邏輯」已經「你中有我，我中有你」了。 按照本重構提出的處方箋，第一步工作是識別出這個繼承體系所承擔的各項責任。 這個繼承體系的職責之一是捕捉不同交易種類間的變化（差異〕，職責之二是捕捉 不同顯示風格之間的變化（差異〕。因此，我們可以得到下列表格： ~~~ Deal Active Deal Passive DealTabular Deal ~~~ 下一步要判斷哪一項職責更重要。很明顯「交易種類」比「顯示風格」重要，因此我們把「交易種類」留在原地，把「顯示風格」提煉到另一個繼承體系中。不過，實際工作中，我們可能需要將「代碼較多」的職責留在原地，這樣一來需要搬移的 代碼數量會比較少。 然后，我們應該使用Extract Class 提煉出一個單獨的PresentationStyle class 用以表示「顯示風格」（如圖12.2）。  圖12.2 添加PresentationStyle ，用以表示「顯示風格」 接下來我們需要針對原繼承體系中的每個subclass ，建立PresentationStyle 的一個個subclasses （如圖 12.3），并將Deal class之中用來保存PresentationStyle 實體的那個instance 變量初始化為適當的subclass 實體：  圖12.3 為PresentationStyle 添加subclasses ~~~ ActiveDeal constructor ...presentation= new SingleActivePresentationStyle();... ~~~ 你可能會說：『這不是比原先的classes 數量還多了嗎？難道這還能讓我的生活更舒服？』生活往往如此：以退為進，走得更遠。對一個糾結成團的繼承體系來說，被提煉出來的另一個繼承體系幾乎總是可以再戲劇性地大量簡化。不過，比較安全的態度是一次一小步，不要過于躁進。 現在，我們要使用 Move Method 和 Move Field，將Deal subclass 中[與顯示邏輯相關」的函數和變量搬移到PresentationStyle 相應的subclasses 去。我們想不出什么好辦法來模擬這個過程，只好請你自己想像。總之，這個步驟完成后，TabularActiveDeal 和 TabularPassiveDeal不再有任何代碼，因此我們將它們移除（如圖12.4）。  圖12.4 與表格相關的 Deal subclass 都移除了 兩項職責被分割之后，我們可以分別簡化兩個繼承體系。一旦本重構完成，我們總是能夠大大簡化被提煉出來的新繼承體系，而且通常還可以簡化原繼承體系。 下一步，我們將擺脫「顯示風格」中的主動（active）與被動（passive）區別，如圖 12.5。  圖12.5 繼承體系被分割了 就連「單一顯示」和「表格顯示」之間的區別，都可以運用若干變量值來捕捉，根本不需要為它們建立subclasses （如圖12.6〕。  圖12.6 「顯示風格」（presentation style）之間的差異可以使用一些變量來表現