但假如被合并的代碼所在的類具有某種并列關系，甚至是同一個父類下的多個子類，或者同一接口的多個實現類，則我們可以采用繼承的方式解決代碼復用的問題。

具體做法是這樣的，第一步還是整理原有的代碼，通過比較，將需要重構的多份原代碼中相同的與不同的代碼整理出來。在整理過程中，可以將不同的代碼，保留在各自的原程序中，而將相同的代碼抽取出來成為獨立的函數。這些函數就是我們后面需要抽象、合并、復用的代碼。

下一步呢，就是運用“抽取父類（Extract Superclass）”的重構手法，從多個要復用的類中抽取出一個共同的父類。父類中包含的方法應當是經過比較后相同的部分，而將不同的部分保留在原有的類中。

舉一個例子吧：在一個開票業務中，開票被分為正常開票與非正常開票。不論是哪種開票，它們都需要保存，因此它們都有save()這個方法。但是，正常開票與非正常開票在保存時，有相同的操作，卻也存在著差異。在我們重構前，“保存”操作在正常開票與非正常開票業務類中各自實現了一遍。顯然，這個方法在兩個類中存在著大量重復的代碼。

隨后我們開始整理與分析。我們發現在整個保存的過程中，保存前的校驗是存在著差異的，但都需要校驗；保存前的數據處理有相同的部分，也是不同的部分；最后執行保存，以及保存后的返回處理是相同的。經過這樣的分析，我們分別將原有的正常開票業務類與非正常開票業務類中的保存操作分為了三段：valid(), prepare()與save()。

最后，我們運用“抽取父類”重構方法，抽取出“開票業務類”這個父類，將valid()設為抽象方法，將prepare()中共同的代碼放在父類中，將save()在父類中實現，將valid()和prepare()中不同的部分，分別在正常開票與非正常開票業務類中各自實現（如圖）：


這里“開票業務類”是個抽象類，不能被實例化。它的valid()方法是個抽象方法，什么都不寫，讓各個子類各自實現去。方法prepare()在父類中實現了公共的部分，但各個子類在實現其不同的部分時，應當調用父類，就像這樣：

    /* 
* @param vo the value of Object
*/
public void prepare(Fp vo) throws IOException {
	super(vo); //調用父類中的公用代碼
	xxxxxxxx;  //編寫子類中各種不同的部分
}
  

最后，save()在兩種開票業務中的代碼完全相同，因此僅僅在父類中編寫，子類不再各自實現。

這樣設計帶來的巨大好處是大大提高了程序的可維護性：如果代碼共同的部分變更了，則去修改父類；如果代碼各自的部分變更了，則去修改子類。如果子類中某些代碼因需求的變更變為了共同的操作，則提升到父類中；相反，父類中某些共同的操作，因需求的變更而不相同時，則降級到子類中分別實現去。

除此之外，還有一種辦法是將不同的部分用一個接口與其多個實現來解決。當實際的應用軟件系統比較復雜時，使用繼承比較容易出現“繼承泛濫”的問題。因此，一個可行的辦法是將繼承轉換為組合，具體方法是這樣做的：

當我們完成了對代碼的比較以后，將代碼不同的部分封裝到一個統一接口下的多個實現類中。然后將代碼相同的部分合并成一個業務類，為各個客戶程序所使用。舉個例子吧，在ERP軟件中有一個功能就是將各種不同的單據生成財務憑證。不同的單據生成的財務憑證是不一樣的，如應付單應當將其對方科目作為憑證的借方科目，將應付科目作為貸方科目；付款單應當將其付款科目作為借方科目，將其結算方式對應的結算方式科目作為貸方科目……但不論哪種單據，盡管科目與規則不同，但都是由一到多個借方分錄和一到多個貸方分錄組成。原程序是分別為各種不同的單據制作憑證生成類，如“應付單憑證生成類”、“付款單憑證生成類”等等，因此出現了大量重復代碼。隨后我們開始重構。通過分析發現，各種不同單據在整個過程中主要是生成分錄的規則不同，同時合并分錄的策略也不相同，但分錄生成與合并分錄之間是一種排列組合關系，即任何一種單據都可能有三種合并方式。不同屬性的排列組合關系最容易造成“繼承的泛濫”，如一個“應付單憑證生成類”，要分解成三個不同合并方式的類，“付款單憑證生成類”同樣要分解為三個。除此之外，讀取單據、保存憑證的過程則是相同的。因此我們進行了如下設計：


這樣的設計，當來了一個業務，要求用多張應付單，按照憑證類型合并的方式生成憑證，則使用“應付單實現類”與“按憑證類型合并”；當另一個用付款單不合并生成憑證時，則使用“付款單實現類”與“不合并憑證”，功能得到實現。

采用該方法重構代碼時，有效地解決了復雜環境下造成“繼承泛濫”的問題，同時提高了系統可維護性。試想，如果要增加一種新的單據，我們則僅僅寫一個它的“分錄生成”實現類就可以了，其它什么都不用管，多么簡便呀。原來的一大堆諸如“應付單憑證生成類”、“付款單憑證生成類”等等，現在一個簡單的“憑證生成業務類”統統都搞定了，程序多么清晰呀。

最后，在復用代碼的過程中，還有一種情況經常出現并且比較討厭，那就是要重構的代碼，被相同的部分與不同的部分分割成了好多的碎片。遇到這種情況，采用繼承結合模板模式的方法，是最有效的了。模板模式（Template Method）是GoF設計模式中的一個，如果你為一個算法定義了一系列步驟，并且允許子類來實現其中的一個或多個步驟，你就可以使用這個模式。該方法將把分離得支離破碎的程序過程，分解成數個方法定義在模板模式的父類中（即每個方法就是一個步驟），并且在父類中定義了這些方法的執行順序。之后，將代碼中相同的部分寫在父類中，將不同的部分分別在子類中實現。

比如，我經常要創建工廠類，雖然每個工廠類都各有各自的不同，但所有工廠類的初始化總是一樣的：采用各種方式（相對路徑、絕對路徑、jar包或zip包中的路徑，等等）尋找XML配置文件、讀取XML文件、解析XML文件中的內容、根據內容創建產品、將產品放入到工廠中、為客戶程序搜索工廠中的產品。這其中第1、2、5步對于任何工廠都是相同的，而第3、4、6步各個工廠卻不盡相同。這時，創建一個AbstractFactoryTemplate的模板類，讓各個工廠去繼承它，則每個工廠類只需實現各自的第3、4、6步，工廠類就快速實現了（如圖）。


提高代碼復用率的方法林林總總、不勝枚舉，并且每種方法都有各自的適用場景。因此，對開發人員提出了很高的技術要求。我們只有在實際工作中多思考、勤練習、仔細體會，才能熟練掌握各項技能，切實提高程序的代碼質量。
（續）

相關文檔
遺留系統：IT攻城獅永遠的痛
需求變更是罪惡之源嗎？
系統重構是個什么玩意兒
我們應當改變我們的設計習慣
小步快跑是這樣玩的（上）
小步快跑是這樣玩的（下）
代碼復用應該這樣做（1）
代碼復用應該這樣做（2）
代碼復用應該這樣做（3）
做好代碼復用不簡單（1）

特別說明：希望網友們在轉載本文時，應當注明作者或出處，以示對作者的尊重，謝謝！

代碼復用應該這樣做（3）