Java 類的設計技巧（學習 Java 編程語言 039）

更能獲得 OOP 圈子承認的類的設計技巧：

1. 必定要保證數據私有。

這是最重要的；絕對不要破壞封裝性。有時候，可能須要編寫一個訪問器方法或更改器方法，可是最好仍是保持實例字段的私有性。不少慘痛的教訓告訴咱們，數據的表示形式極可能會改變，但它們的使用方式卻不會常常變化。當數據保持私有時，表示形式的變化不會對類的使用者產生影響，並且也更容易檢測 bug。

2. 必定要對數據進行初始化。

Java 不會爲你初始化局部變量，可是會對對象的實例字段進行初始化。最好不要依賴於系統的默認值，而是應該顯式地初始化全部的數據，能夠提供默認值，也能夠在全部構造器中設置默認值。

3. 不要在類中使用過多的基本類型。

這個想法是要用其餘的類替換使用多個相關的基本類型。這樣會使類更易於理解，也更於修改。例如，用一個名爲 Address 的新類替換一個 Customer 類中一下的實例字段：
 private String street;
 private String city;
 private String state;
 private int zip;
這樣一來，能夠很容易地處理地址的變化，例如，可能須要處理國際地址。

4. 不是全部的字段都須要單獨的字段訪問器和字段更改器。

你可能須要得到或設置員工的工資。而一旦構造了對象，確定不須要更改僱傭日期。另外，在對象中，經常包含一些不但願別人得到或設置的實例字段，例如，Address 類中的州縮寫數組。

5. 分解有過多職責的類。

這樣說彷佛有點含糊，究竟多少算是「過多」？每一個人的見解都不一樣。可是，若是明顯地能夠將一個複雜的類分解成兩個更爲簡單的類，就應該將其分解（但另外一方面，也不要走極端，若是設計 10 個類，每一個類只有一個方法，顯然就有些矯枉過正了）。

下面是一個反面的設計示例。

// 壞的設計
public class CardDeck
{
    private int[] value;
    private int[] suit;

    public CardDeck() { ... }
    public void shuffle() { ... }
    public int getTopValue() { . . . }
    public int getTopSuit() { . . . }
    public void draw() { .. }
}

實際上，這個類實現了兩個獨立的概念：一副牌（含有 shuffle 方法和 draw 方法）和一張牌（含有查看面值和花色的方法)。最好引入一個表示一張牌的 Card 類。如今有兩個類，每一個類完成本身的職責：

public class CardDeck {
    private Card[] cards;

    public CardDeck() { ... }
    public void shuffle() { ... }
    public Card getTop() { ... }
    public void draw() { ... }
}

public class Card {
    private int value;
    private int suit;

    public Card (int aValue, int aSuit) { ... }
    public int getValue() { ... } 
    public int getSuit() { ... }
}

6. 類名和方法名要可以體現它們的職責。

與變量應該有一個可以反映其含義的名字同樣，類也應該如此（在標準類庫中，也存在着一些含義不明確的例子，如 Date 類其實是一個用於描述時間的類 )。

對此有一個很好的慣例：類名應當是一個名詞（Order），或者是前面有形容詞修飾的名詞（RushOrder），或者是有動名詞（有「 -ing」 後綴）修飾的名詞（例如，BillingAddress）。對於方法來講，要遵循的標準慣例：訪問器方法用小寫 get 開頭，更改器方法用小寫的 set 開頭。

7.優先使用不可變的類。

LocalDate 類以及 java.time 包中的其餘類是不可變的——沒有方法能修改對象的狀態。相似 plusDays 的方法並非更改對象，而是返回狀態已修改的新對象。

更改對象的問題在於，若是多個線程試圖同時更新一個對象，就會發生併發更改。其結果是不可預料的。若是類是不可變的，就能夠安全地在多個線程間共享其對象。

所以，要儘量讓類是不可變的，這是一個很好的想法。對於表示值的類，如一個字符串或一個時間點，這尤爲容易。計算會生成新值，而不是更新原來的值。

固然，並非全部類都應當是不可變的。若是員工加薪的方法返回一個新的員工對象，這會很奇怪。