更優秀的Java程式碼-技巧篇1

孤獨的俠客發表於2017-10-11
Java

原文：4 More Techniques for Writing Better Java
作者：Justin Albano
翻譯：Vincent


譯者注：如果現在要求對你寫的Java程式碼進行優化，那你會怎麼做呢？作者在本文介紹了可以提高系統效能以及程式碼可讀性的四種方法，如果你對此感興趣，就讓我們一起來看看吧。以下為譯文。

我們平時的程式設計任務不外乎就是將相同的技術套件應用到不同的專案中去，對於大多數情況來說，這些技術都是可以滿足目標的。然而，有的專案可能需要用到一些特別的技術，因此工程師們得深入研究，去尋找那些最簡單但最有效的方法。在前一篇文章中，我們討論了必要時可以使用的四種特殊技術，這些特殊技術可以建立更好的Java軟體；而本文我們將介紹一些有助於解決常見問題的通用設計策略和目標實現技術，即：


  1. 只做有目的性的優化
  2. 常量儘量使用列舉
  3. 重新定義類裡面的equals()方法
  4. 儘量多使用多型性

值得注意的是，本文中描述的技術並不是適用於所有情況。另外這些技術應該什麼時候使用以及在什麼地方使用，都是需要使用者經過深思熟慮的。

1 .只做有目的性的優化

大型軟體系統肯定非常關注效能問題。雖然我們希望能夠寫出最高效的程式碼，但很多時候，如果想對程式碼進行優化，我們卻無從下手。例如，下面的這段程式碼會影響到效能嗎?

public void processIntegers(List<Integer> integers) {


for (Integer value: integers) {
    for (int i = integers.size() - 1; i &gt;= 0; i--) {
        value += integers.get(i);
    }
}




}

這就得視情況而定了。上面這段程式碼可以看出它的處理演算法是O(n³)(使用大O符號)，其中n是list集合的大小。如果n只有5，那麼就不會有問題，只會執行25次迭代。但如果n是10萬，那可能會影響效能了。請注意，即使這樣我們也不能判定肯定會有問題。儘管此方法需要執行10億次邏輯迭代，但會不會對效能產生影響仍然有待討論。

例如，假設客戶端是在它自己的執行緒中執行這段程式碼，並且非同步等待計算完成，那麼它的執行時間有可能是可以接受的。同樣，如果系統部署在了生產環境上，但是沒有客戶端進行呼叫，那我們根本沒必要去對這段程式碼進行優化，因為壓根就不會消耗系統的整體效能。事實上，優化效能以後系統會變得更加複雜，悲劇的是系統的效能卻沒有因此而提高。

最重要的是天下沒有免費的午餐，因此為了降低代價，我們通常會通過類似於快取、迴圈展開或預計算值這類技術去實現優化，這樣反而增加了系統的複雜性，也降低了程式碼的可讀性。如果這種優化可以提高系統的效能，那麼即使變得複雜，那也是值得的，但是做決定之前，必須首先知道這兩條資訊：


  1. 效能要求是什麼
  2. 效能瓶頸在哪裡

首先我們需要清楚地知道效能要求是什麼。如果最終是在要求以內，並且終端使用者也沒有提出什麼異議，那麼就沒有必要進行效能優化。但是，當新增了新功能或者系統的資料量達到一定規模以後就必須進行優化了，否則可能會出現問題。

在這種情況下，不應該靠直覺，也不應該依靠檢查。因為即使是像Martin Fowler這樣有經驗的開發人員也容易做一些錯誤的優化，正如在重構(第70頁)一文中解釋的那樣：


如果分析了足夠多的程式以後，你會發現關於效能的有趣之處在於，大部分時間都浪費在了系統中的一小部分程式碼中裡面。如果對所有程式碼進行了同樣的優化，那麼最終結果就是浪費了90%的優化，因為優化過以後的程式碼執行得頻率並不多。因為沒有目標而做的優化所耗費的時間，都是在浪費時間。


作為一名身經百戰的開發人員，我們應該認真對待這一觀點。第一次猜測不僅沒有提高系統的效能，而且90%的開發時間完全是浪費了。相反，我們應該在生產環境(或者預生產環境中)執行常見用例，並找出在執行過程中是哪部分在消耗系統資源，然後對系統進行配置。例如消耗大部分資源的程式碼只佔了10%，那麼優化其餘90%的程式碼就是浪費時間。

根據分析結果，要想使用這些知識，我們應該從最常見的情況入手。因為這將確保實際付出的努力最終是可以提高系統的效能。每次優化後，都應該重複分析步驟。因為這不僅可以確保系統的效能真的得到了改善，也可以看出再對系統進行優化後，效能瓶頸是在哪個部分(因為解決完一個瓶頸以後,其它瓶頸可能消耗系統更多的整體資源)。需要注意的是，在現有瓶頸中花費的時間百分比很可能會增加，因為剩下的瓶頸是暫時不變的，而且隨著目標瓶頸的消除，整個執行時間應該會減少。

儘管在Java系統中想要對概要檔案進行全面檢查需要很大的容量，但是還是有一些很常見的工具可以幫助發現系統的效能熱點，這些工具包括JMeter、AppDynamics和YourKit。另外，還可以參見DZone的效能監測指南，獲取更多關於Java程式效能優化的資訊。

雖然效能是許多大型軟體系統一個非常重要的組成部分，也成為產品交付管道中自動化測試套件的一部分，但是還是不能夠盲目的且沒有目的的進行優化。相反，應該對已經掌握的效能瓶頸進行特定的優化。這不僅可以幫助我們避免增加了系統的複雜性，而且還讓我們少走彎路，不去做那些浪費時間的優化。

2.常量儘量使用列舉

需要使用者列出一組預定義或常量值的場景有很多，例如在web應用程式中可能遇到的HTTP響應程式碼。最常見的實現技術之一是新建類，該類裡面有很多靜態的final型別的值，每個值都應該有一句註釋，描述該值的含義是什麼:

public class HttpResponseCodes { 

    public static final int OK = 200; 

    public static final int NOT_FOUND = 404; 

    public static final int FORBIDDEN = 403; 

} 

if (getHttpResponse().getStatusCode() == HttpResponseCodes.OK) { 

    // Do something if the response code is OK  

}

能夠有這種思路就已經非常好了，但這還是有一些缺點：


  1. 沒有對傳入的整數值進行嚴格的校驗
  2. 由於是基本資料型別，因此不能呼叫狀態程式碼上的方法

在第一種情況下只是簡單的建立了一個特定的常量來表示特殊的整數值，但並沒有對方法或變數進行限制，因此使用的值可能會超出定義的範圍。例如:

public class HttpResponseHandler { 

    public static void printMessage(int statusCode) { 

        System.out.println("Recieved status of " + statusCode);  

    } 

} 

HttpResponseHandler.printMessage(15000);

儘管15000並不是有效的HTTP響應程式碼，但是由於伺服器端也沒有限制客戶端必須提供有效的整數。在第二種情況下，我們沒有辦法為狀態程式碼定義方法。例如，如果想要檢查給定的狀態程式碼是否是一個成功的程式碼，那就必須定義一個單獨的函式:

public class HttpResponseCodes { 

    public static final int OK = 200; 

    public static final int NOT_FOUND = 404; 

    public static final int FORBIDDEN = 403; 

    public static boolean isSuccess(int statusCode) { 

        return statusCode >= 200 && statusCode < 300;  

    } 

} 

if (HttpResponseCodes.isSuccess(getHttpResponse().getStatusCode())) { 

    // Do something if the response code is a success code  

}

為了解決這些問題，我們需要將常量型別從基本資料型別改為自定義型別，並只允許自定義類的特定物件。這正是Java列舉(enum)的用途。使用enum，我們可以一次性解決這兩個問題:

public enum HttpResponseCodes { 

    OK(200), 

    FORBIDDEN(403), 

    NOT_FOUND(404); 

    private final int code;  

    HttpResponseCodes(int code) { 

        this.code = code; 

    } 

    public int getCode() { 

        return code; 

    } 

    public boolean isSuccess() { 

        return code >= 200 && code < 300; 

    } 

} 

if (getHttpResponse().getStatusCode().isSuccess()) { 

    // Do something if the response code is a success code  

}

同樣，現在還可以要求在呼叫方法的時候提供必須有效的狀態程式碼：

public class HttpResponseHandler { 

    public static void printMessage(HttpResponseCode statusCode) { 

        System.out.println("Recieved status of " + statusCode.getCode());  

    } 

} 

HttpResponseHandler.printMessage(HttpResponseCode.OK);

值得注意的是，舉這個例子事項說明如果是常量，則應該儘量使用列舉，但並不是說什麼情況下都應該使用列舉。在某些情況下，可能希望使用一個常量來表示某個特殊值，但是也允許提供其它的值。例如，大家可能都知道圓周率，我們可以用一個常量來捕獲這個值(並重用它):

public class NumericConstants { 

    public static final double PI = 3.14; 

    public static final double UNIT_CIRCLE_AREA = PI * PI; 

} 

public class Rug { 

    private final double area; 

    public class Run(double area) { 

        this.area = area; 

    } 

    public double getCost() { 

        return area * 2; 

    } 

} 

// Create a carpet that is 4 feet in diameter (radius of 2 feet) 

Rug fourFootRug = new Rug(2 * NumericConstants.UNIT_CIRCLE_AREA);

因此，使用列舉的規則可以歸納為:

當所有可能的離散值都已經提前知道了，那麼就可以使用列舉

再拿上文中所提到的HTTP響應程式碼為例，我們可能知道HTTP狀態程式碼的所有值(可以在RFC 7231中找的到，它定義了HTTP 1.1協議)。因此使用了列舉。在計算圓周率的情況下，我們不知道關於圓周率的所有可能值(任何可能的double都是有效的)，但同時又希望為圓形的rugs建立一個常量，使計算更容易(更容易閱讀);因此定義了一系列常量。

如果不能提前知道所有可能的值，但是又希望包含每個值的欄位或方法，那麼最簡單的方法就是可以新建一個類來表示資料。儘管沒有說過什麼場景應該絕對不用列舉，但要想知道在什麼地方、什麼時間不使用列舉的關鍵是提前意識到所有的值，並且禁止使用其他任何值。

3.重新定義類裡面的equals()方法

物件識別可能是一個很難解決的問題：如果兩個物件在記憶體中佔據相同的位置，那麼它們是相同的嗎?如果它們的id相同，它們是相同的嗎?或者如果所有的欄位都相等呢?雖然每個類都有自己的標識邏輯，但是在系統中有很多西方都需要去判斷是否相等。例如，有如下的一個類，表示訂單購買…

public class Purchase { 

    private long id; 

    public long getId() { 

        return id; 

    } 

    public void setId(long id) { 

        this.id = id; 

    } 

}

……就像下面寫的這樣，程式碼中肯定有很多地方都是類似於的:

Purchase originalPurchase = new Purchase(); 

Purchase updatedPurchase = new Purchase(); 

if (originalPurchase.getId() == updatedPurchase.getId()) { 

    // Execute some logic for equal purchases  

}

這些邏輯呼叫的越多(反過來，違背了DRY原則)，Purchase類的身份資訊也會變得越來越多。如果出於某種原因，更改了Purchase類的身份邏輯(例如，更改了識別符號的型別)，則需要更新標識邏輯所在的位置肯定也非常多。

我們應該在類的內部初始化這個邏輯，而不是通過系統將Purchase類的身份邏輯進行過多的傳播。乍一看，我們可以建立一個新的方法，比如isSame，這個方法的入參是一個Purchase物件，並對每個物件的id進行比較，看看它們是否相同:

public class Purchase { 

    private long id; 

    public boolean isSame(Purchase other) { 

        return getId() == other.gerId(); 

    } 

}

雖然這是一個有效的解決方案，但是忽略了Java的內建功能:使用equals方法。Java中的每個類都是繼承了Object類，雖然是隱式的，因此同樣也就繼承了equals方法。預設情況下，此方法將檢查物件標識(記憶體中相同的物件)，如JDK中的物件類定義(version 1.8.0_131)中的以下程式碼片段所示:

public boolean equals(Object obj) { 

    return (this == obj); 

}

這個equals方法充當了注入身份邏輯的自然位置(通過覆蓋預設的equals實現):

public class Purchase { 

    private long id; 

    public long getId() { 

        return id; 

    } 

    public void setId(long id) { 

        this.id = id; 

    } 

    @Override 

    public boolean equals(Object other) { 

        if (this == other) { 

            return true; 

        } 

        else if (!(other instanceof Purchase)) { 

            return false; 

        } 

        else { 

            return ((Purchase) other).getId() == getId(); 

        } 

    } 

}

雖然這個equals方法看起來很複雜，但由於equals方法只接受型別物件的引數，所以我們只需要考慮三個案例:


  1. 另一個物件是當前物件(即originalPurchase.equals(originalPurchase))，根據定義，它們是同一個物件，因此返回true

  2. 另一個物件不是Purchase物件，在這種情況下，我們無法比較Purchase的id，因此，這兩個物件不相等

  3. 其他物件不是同一個物件，但卻是Purchase的例項,因此,是否相等取決於當前Purchase的id和其他Purchase是否相等

現在可以重構我們之前的條件，如下:

Purchase originalPurchase = new Purchase(); 

Purchase updatedPurchase = new Purchase(); 

if (originalPurchase.equals(updatedPurchase)) { 

    // Execute some logic for equal purchases  

}

除了可以在系統中減少複製，重構預設的equals方法還有一些其它的優勢。例如，如果構造一個Purchase物件列表，並檢查列表是否包含具有相同ID(記憶體中不同物件)的另一個Purchase物件，那麼我們就會得到true值，因為這兩個值被認為是相等的:

List<Purchase> purchases = new ArrayList<>(); 

purchases.add(originalPurchase); 

purchases.contains(updatedPurchase); // True

通常，無論在什麼地方，如果需要判斷兩個類是否相等，則只需要使用重寫過的equals方法就可以了。如果希望使用由於繼承了Object物件而隱式具有的equals方法去判斷相等性，我們還可以使用= =操作符，如下:

if (originalPurchase == updatedPurchase) { 

    // The two objects are the same objects in memory  

}

還需要注意的是，當equals方法被重寫以後，hashCode方法也應該被重寫。有關這兩種方法之間關係的更多資訊，以及如何正確定義hashCode方法，請參見此執行緒。

正如我們所看到的，重寫equals方法不僅可以將身份邏輯在類的內部進行初始化，並在整個系統中減少了這種邏輯的擴散，它還允許Java語言對類做出有根據的決定。

4.儘量多使用多型性

對於任何一門程式語言來說，條件句都是一種很常見的結構，而且它的存在也是有一定原因的。因為不同的組合可以允許使用者根據給定值或物件的瞬時狀態改變系統的行為。假設使用者需要計算各銀行賬戶的餘額，那麼就可以開發出以下的程式碼:

public enum BankAccountType { 

    CHECKING, 

    SAVINGS, 

    CERTIFICATE_OF_DEPOSIT; 

} 

public class BankAccount { 

    private final BankAccountType type; 

    public BankAccount(BankAccountType type) { 

        this.type = type; 

    } 

    public double getInterestRate() { 

        switch(type) { 

            case CHECKING: 

                return 0.03; // 3% 

            case SAVINGS: 

                return 0.04; // 4% 

            case CERTIFICATE_OF_DEPOSIT: 

                return 0.05; // 5% 

            default: 

                throw new UnsupportedOperationException(); 

        } 

    } 

    public boolean supportsDeposits() { 

        switch(type) { 

            case CHECKING: 

                return true; 

            case SAVINGS: 

                return true; 

            case CERTIFICATE_OF_DEPOSIT: 

                return false; 

            default: 

                throw new UnsupportedOperationException(); 

        } 

    } 

}

雖然上面這段程式碼滿足了基本的要求，但是有個很明顯的缺陷:使用者只是根據給定帳戶的型別決定系統的行為。這不僅要求使用者每次要做決定之前都需要檢查賬戶型別，還需要在做出決定時重複這個邏輯。例如，在上面的設計中，使用者必須在兩種方法都進行檢查才可以。這就可能會出現失控的情況，特別是接收到新增新帳戶型別的需求時。

我們可以使用多型來隱式地做出決策，而不是使用賬戶型別用來區分。為了做到這一點，我們將BankAccount的具體類轉換成一個介面，並將決策過程傳入一系列具體的類，這些類代表了每種型別的銀行帳戶:

public interface BankAccount { 

    public double getInterestRate(); 

    public boolean supportsDeposits(); 

} 

public class CheckingAccount implements BankAccount { 

    @Override 

    public double getIntestRate() { 

        return 0.03; 

    } 

    @Override 

    public boolean supportsDeposits() { 

        return true; 

    } 

} 

public class SavingsAccount implements BankAccount { 

    @Override 

    public double getIntestRate() { 

        return 0.04; 

    } 

    @Override 

    public boolean supportsDeposits() { 

        return true; 

    } 

} 

public class CertificateOfDepositAccount implements BankAccount { 

    @Override 

    public double getIntestRate() { 

        return 0.05; 

    } 

    @Override 

    public boolean supportsDeposits() { 

        return false; 

    } 

}

這不僅將每個帳戶特有的資訊封裝到了到自己的類中，而且還支援使用者可以在兩種重要的方式中對設計進行變化。首先，如果想要新增一個新的銀行帳戶型別，只需建立一個新的具體類，實現了BankAccount的介面，給出兩個方法的具體實現就可以了。在條件結構設計中，我們必須在列舉中新增一個新值，在兩個方法中新增新的case語句，並在每個case語句下插入新帳戶的邏輯。

其次，如果我們希望在BankAccount介面中新增一個新方法，我們只需在每個具體類中新增新方法。在條件設計中，我們必須複製現有的switch語句並將其新增到我們的新方法中。此外，我們還必須在每個case語句中新增每個帳戶型別的邏輯。

在數學上，當我們建立一個新方法或新增一個新型別時，我們必須在多型和條件設計中做出相同數量的邏輯更改。例如，如果我們在多型設計中新增一個新方法，我們必須將新方法新增到所有n個銀行帳戶的具體類中，而在條件設計中，我們必須在我們的新方法中新增n個新的case語句。如果我們在多型設計中新增一個新的account型別，我們必須在BankAccount介面中實現所有的m數，而在條件設計中，我們必須向每個m現有方法新增一個新的case語句。

雖然我們必須做的改變的數量是相等的，但變化的性質卻是完全不同的。在多型設計中，如果我們新增一個新的帳戶型別並且忘記包含一個方法，編譯器會丟擲一個錯誤，因為我們沒有在我們的BankAccount介面中實現所有的方法。在條件設計中，沒有這樣的檢查，以確保每個型別都有一個case語句。如果新增了新型別，我們可以簡單地忘記更新每個switch語句。這個問題越嚴重，我們就越重複我們的switch語句。我們是人類，我們傾向於犯錯誤。因此，任何時候，只要我們可以依賴編譯器來提醒我們錯誤，我們就應該這麼做。

關於這兩種設計的第二個重要注意事項是它們在外部是等同的。例如，如果我們想要檢查一個支票帳戶的利率，條件設計就會類似如下:

BankAccount checkingAccount = new BankAccount(BankAccountType.CHECKING); 

System.out.println(checkingAccount.getInterestRate()); // Output: 0.03

相反，多型設計將類似如下:

BankAccount checkingAccount = new CheckingAccount(); 

System.out.println(checkingAccount.getInterestRate()); // Output: 0.03

從外部的角度來看，我們只是在BankAccount物件上呼叫getintereUNK()。如果我們將建立過程抽象為一個工廠類的話，這將更加明顯:

public class ConditionalAccountFactory { 

    public static BankAccount createCheckingAccount() { 

         return new BankAccount(BankAccountType.CHECKING); 

    } 

} 

public class PolymorphicAccountFactory { 

    public static BankAccount createCheckingAccount() { 

         return new CheckingAccount(); 

    } 

} 

// In both cases, we create the accounts using a factory 

BankAccount conditionalCheckingAccount = ConditionalAccountFactory.createCheckingAccount(); 

BankAccount polymorphicCheckingAccount = PolymorphicAccountFactory.createCheckingAccount(); 

// In both cases, the call to obtain the interest rate is the same 

System.out.println(conditionalCheckingAccount.getInterestRate()); // Output: 0.03 

System.out.println(polymorphicCheckingAccount.getInterestRate()); // Output: 0.03

將條件邏輯替換成多型類是非常常見的，因此已經發布了將條件語句重構為多型類的方法。這裡就有一個簡單的例子。此外，馬丁·福勒(Martin Fowler)的《重構》(p . 255)也描述了執行這個重構的詳細過程。

就像本文中的其他技術一樣，對於何時執行從條件邏輯轉換到多型類，沒有硬性規定。事實上，如論在何種情況下我們都是不建議使用。在測試驅動的設計中：例如，Kent Beck設計了一個簡單的貨幣系統，目的是使用多型類，但發現這使設計過於複雜，於是便將他的設計重新設計成一個非多型風格。經驗和合理的判斷將決定何時是將條件程式碼轉換為多型程式碼的合適時間。

結束語

作為程式設計師，儘管平常所使用的常規技術可以解決大部分的問題，但有時我們應該打破這種常規，主動需求一些創新。畢竟作為一名開發人員，擴充套件自己知識面的的廣度和深度，不僅能讓我們做出更明智的決定，也能讓我們變得越來越聰明。


相關文章