由于軟件工程的復雜性，一個大型的軟件常常被切割成不同的子軟件模塊，并由不同的團隊承擔。假設一個大型的軟件分為三個子模塊：

·A模塊：底層處理類模塊。

·B模塊：高層業務模塊1。

·C模塊：高層業務模塊2。

A模塊作為底層的模塊，會被B和C模塊調用，但因為A模塊由單獨的團隊開發（在JBuilder中表現為單獨的工程），A模塊的重構僅在當前工程中進行。JBuilder會記錄重構軌跡，并允許你通過JAR檔案包含這些重構的記錄，當B及C模塊工程通過工程類庫重新引入A的JAR檔案文件時，可以將在A工程中的重構應用于B及C模塊工程。這種重構，解決了關聯工程間的重構問題，稱為分布式重構。

為了演示分布式重構，我們重新創建了一個新的工程common_lib，開發一個DateUtils類：

代碼清單 21 DateUtils類

1. package common_lib; 2. public class DateUtils { 3. public static String getNowTime() 4. { 5. return ""+(new java.util.Date()); 6. } 7. }

將common_lib工程打成common_lib.jar包輸出，并在myrefactor工程目錄下創建一個extralib子文件夾，將common_lib.jar拷貝到這個文件夾中，在工程擴展類庫中引用這個JAR包。

在myrefactor中新建一個Distribute類，引用common_lib.jar中的DateUtils.getNowTime()，其代碼如下所示：

代碼清單 22 在myrefactor工程中引用common_lib工程的類

1. package myrefactor ; 2. import common_lib.DateUtils; 3. public class Distribute 4. { 5. public void printCurrTime() 6. { 7. System.out.println(DateUtils.getNowTime()) ; 8. } 9. }

過了一段時間，common_lib工程的負責人對DateUtils.getNowTime()方法名進行重構，將其更名為getCurrTime()。通過Refactor->Refactoring History...調出Refactoring History對話框，如下圖所示：

圖 30 重構歷史記錄

對話框中列出了當前工程所有重構歷史記錄，也許你不希望將所有的重構都分發出去，那么你可以通過Remove按鈕刪除那些重構記錄。

為了這個方法重命名重構分發到引用了工程的其他工程中，需要在打包時包括重構的信息。

如果common_lib工程資源樹中已經有了一個打包節點，僅需右擊該節點在彈出菜單中選擇Properties更改打包的設置即可，在彈出的Properties for ‘Archive’選擇Refactoring設置頁，如下圖所示：

圖 31

在檔案文件中包含重構記錄

重新打包生成common_lib.jar檔案文件，將這個檔案文件覆蓋<myrefactor工程目錄>/extralib/common_lib.jar。

打開myrefactor.jpx工程，通過Refactor->Distributed Refactorings...打開Distributed Refactorings對話框，切換到Pending Refactorings標簽頁，如下圖所示：

圖 32 未決的重構列表

由于我們在common_lib工程中對DateUtils類的getNowTime()重構為getCurrTime()，所以列表中僅中一條記錄，記錄簡要描述了重構的變化。

注意：

如果你在打開工程的同時覆蓋common_lib.jar，Distributed Refactorings對話框的Pending Refactorings標簽頁中并不會列出未決重構項，此時，你需要關閉并重啟myrefactor.jpx工程。

在列表中選擇這條未決的重構記錄，點擊Apply應用這個重構，Distribute類的調用被更改過來：

代碼清單 23 應用分式重構后的Distribute類

1. … 2. public class Distribute 3. { 4. public void printCurrTime() 5. { 6. System.out.println(DateUtils.getCurrTime()) ; 7. } 8. }

你也可以通過ErrorInsight應用分布式的重構：在工程擴展類型被的API被更改后，引用到發生重構類的當前工程類的結構窗格會出現一個 圖標，右擊這個圖標，在彈出的菜單中選擇重構修復菜單項，如這個Distribute類，我們可以選擇Refactor Method，彈出如下的對話框：

圖 33 通過ErrorInsight進行重構修復的對話框

點擊OK，JBuilder不但會在當前類中應用這個方法的重構，還會在查找當前工程中其他引用這getNowTime()方法的地方，一并重構。

切換到 圖 32的Completed Refactorings標簽頁中將列出所有完成的重構項。

總結

有了重構，就應當盡量少用替換功能了，重構保證了更改的安全性和一致性。有了JBuilder重構功能的支持，對工程進行代碼重構有如行云流水，一氣呵成。重構不是階段性的工作，當你一發現代碼隊伍陣腳不齊，或說聞到代碼的壞味道時，就應該進行重構了。即使你的工程已經被其他工程當成API使用，也不必擔心，JBuilder分布式重構的功能使開發伙伴團隊只需要少許的工作，就可以保持代碼的一致性了。

當然JBuilder只是提供了各種重構的操作，要知道如何通過重構優化代碼，也許你需要閱讀一些其他的書籍，本文一再提及Martin Fowler的《重構——改善既有代碼的設計》，就把這本書再向讀者朋友推薦一下吧。

全文完