摘自《Java核心技術》卷一

1. 一定要保證資料私有

這是最重要的; 絕對不要破壞封裝性。

有時候，需要編寫一個訪問器方法或更改器方法，但是最好還是保持例項域的私有性。很多慘痛的經驗告訴我們， 資料的表示形式很可能會改變，但它們的使用方式卻不會經常發生變化。

當資料保持私有時，它們的表示形式的變化不會對類的使用者產生影響，即使出現 bug 也易於檢測。

2. 一定要對資料初始化

Java 不對區域性變數進行初始化， 但是會對物件的例項域進行初始化。

最好不要依賴於系統的預設值， 而是應該顯式地初始化所有的資料， 具體的初始化方式可以是提供預設值， 也可以是在所有構造器中設定預設值。

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

就是說，用其他的類代替多個相關的基本型別的使用。這樣會使類更加易於理解且易於修改。例如， 用一個稱為 Address 的新的類替換一個 Customer 類中以下的例項域:

private String street;
private String city; 
private String state;
private int zip;

這樣， 可以很容易處理地址的變化， 例如， 需要增加對國際地址的處理。

4. 不是所有的域都需要獨立的域訪問器和域更改器
或許，需要獲得或設定僱員的薪金。 而一旦構造了僱員物件， 就應該禁止更改僱用日期， 並且在物件中， 常常包含一些不希望別人獲得或設定的例項域， 例如，在 Address 類中， 存放州縮寫的陣列。

5. 將職責過多的類進行分解

這樣說似乎有點含糊不清， 究竟多少算是“ 過多” ? 每個人的看法不同。但是， 如果明顯地可以將一個複雜的類分解成兩個更為簡單的類， 就應該將其分解(但另一方面， 也不要走極端。 設計 10 個類， 每個類只有一個方法， 顯然有些矯枉過正了)。

6. 類名和方法名要能夠體現它們的職責

與變數應該有一個能夠反映其含義的名字一樣， 類也應該如此(在標準類庫中， 也存在著一些含義不明確的例子， 如: Date 類實際上是一個用於描述時間的類 )。

命名類名的良好習慣是採用一個名詞(Order)、 前面有形容詞修飾的名詞( RushOrder) 或動名詞(有“ -ing”字尾)修飾名詞(例如，BillingAddress)。對於方法來說，習慣是訪問 器方法用小寫 get 開頭 ( getSalary ), 更改器方法用小寫的 set 開頭(setSalary )

7. 優先使用不可變的類 

LocalDate 類以及 java.time 包中的其他類是不可變的 沒有方法能修改物件的狀態。 類似 plusDays 的方法並不是更改物件， 而是返回狀態已修改的新物件。

更改物件的問題在於， 如果多個執行緒試圖同時更新一個物件， 就會發生併發更改。其結果是不可預料的。 如果類是不可變的， 就可以安全地在多個執行緒間共享其物件。