第十九計：避免類的臃腫

??在我接觸過的大部分項目中，總會有一個“大胖子“類特別惹眼，一般來說，這“大胖子“實際上是整個系統的核心類之一，之所以“胖“，主要原因是很多人都會把自己需要的函數加到這個類中，卻沒有人主動請纓來為它“減肥“。可以通過以下幾種方式來為它“瘦身”：

??1、按照某種特性（如功能、類型等）將這個類拆分成多個類。

? 2、合并冗余函數，保持函數粒度的最小化。

? 3、去除重復代碼。

??如果實在不能再“瘦”了，那就通過實現相應的接口，讓它“看上去很瘦“，舉個例子：

??

public class BigBoy{public void foo1();public void foo2();public void foo3();public void foo4();public void foo5();public void foo6();public void foo7();public void foo8();public void foo9();// 還有很多... }

?

這個類有很多函數，這讓類的使用者很頭疼，沒辦法，它不能再“瘦“了，不過，我們可以根據某種特性把這些函數抽象成多個接口，例如foo1、foo2、foo3可以抽象成一個接口：

public interface LittleBoy{public void foo1();public void foo2();public void foo3(); }

?

然后讓BigBoy實現這個接口，并提供一個將BigBoy變成LitterBoy的函數：

?

?

public class BigBoy implements LittleBoy{public LittleBoy asLittleBoy{)return this;}public void foo1();public void foo2();public void foo3();public void foo4();public void foo5();public void foo6();public void foo7();public void foo8();public void foo9();// 還有很多... }

?

這樣，類的使用者得到將是“瘦版“的BigBoy，使用難度大大降低了，因此，對于需要使用該類所有函數中某個子集的用戶，我們可以提供一個包含該函數子集的接口實現對象即可。

?

第二十計：保持代碼風格的一致性

??程序員或多或少都有各自的代碼風格，當我們看和自己風格不同的人寫的代碼時都覺得有點別扭，甚至會影響讀代碼的流暢性，記得以前有個同事把for語句當if語句用，像下面這樣，太個性了，看他的代碼真有點頭疼。

??

for(;value>10;){... }

整個程序保持一致的代碼風格還是比較重要的，如果看著就像一個人寫那就太到位了，所以，最好能在項目初期就統一程序的命名規范、通過邏輯處理規范、注釋規范等。

?

第二十一計：成員變量要封裝

??大部分情況下，類中的成員變量都應該被聲明為私有的，為那些需要被其他類訪問的變量增加set或者get函數。如果成員變量聲明為公有的，那么類就失去了對它們的控制權！封裝成員變量有以下幾個好處：

? 1、在為成員變量賦值時進行有效性校驗或其他預處理操作。

? 2、在返回成員變量的值時進行二次包裝，當該變量不可用或未初始化時返回默認值。

? 為成員變量分別增加set和get函數是一件挺繁瑣的事情，很多人嫌麻煩，覺得公有成員變量更方便，不過從可維護性和可擴展性的角度看，添加set和get是值得的，Eclipse中可以自動生成set和get函數的，非常方便。

?

第二十二計：用自注釋性變量代替復雜條件

??嵌套層次較深的IF判斷、沒有注釋的復雜條件大大增加了程序的邏輯復雜性，嚴重降低代碼的可讀性。對于子條件較多的條件判定，可以為各個子條件引入具有自注釋性的臨時變量來降低復雜性。例如下面是判斷登錄用戶是否能進入網站的后臺管理界面：

??

if(userName!=null && userName.equals(name) && (userState != INACTIVE || userState != DELETE) && userPassword!=null && userPassword.equals(password) && (userGroup == "Manager" || userGroup == "Root")){... }

?

?

? 下面是修改后的版本：

boolean isUserNameValid = userName!=null && userName.equals(name); boolean isUserActive = userState != INACTIVE || userState != DELETE;boolean isUserPasswordCorrect = userPassword!=null && userPassword.equals(password);boolean isUserHasAuth = userGroup == "Manager" || userGroup == "Root";
if(isUserNameValid && isUserActive && isUserPasswordCorrect && isUserHasAuth){...}

?

第二種方式不僅使條件判斷更具有可讀性，還能重用子條件。

?

第二十三計：避免重復代碼

??重復代碼是破壞程序可維護性的重量級選手之一，大量的重復代碼會使代碼量膨脹，修改重復的代碼也很繁瑣，改了一處后必須同時修改和它重復的代碼，因此非常引入Bug，當有人修改了某處代碼而忘記修改其他除重復的代碼，那么Bug就出現了。所以，一旦要拷貝某段代碼，請先考慮把這段代碼通用化。

?

第二十四計：增加注釋

??記得在第一個公司工作的時候，公司很多程序員的代碼注釋率在40%左右，一般都是先寫注釋，然后緊接著寫代碼，因為注釋也是一種文檔。很多人覺得寫注釋浪費時間或者沒有必要，所以他們的代碼中沒有綠色，或者只是星星點點，如果代碼有一定的復雜性，那么其他人看這部分代碼可能會比代碼作者要費勁的多，注釋就是幫助別人快速理解自己寫的代碼。

?

轉載于:https://www.cnblogs.com/west-link/archive/2012/04/18/2447071.html

總結

以上是生活随笔為你收集整理的重构36计（4）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。