在Java面向物件程式設計的過程中,類的設計是一個很有挑戰性的工作,不同的人可能對於類的理解不一樣,設計出來的類也可能不一樣,下文yjbys小編為大家分享的是關於java類的設計技巧，希望對大家學習java有幫助!
1)一定將資料設計為私有。
最重要的是：絕對不要破壞封裝性。有時候，需要編寫一個訪問器方法或更改器方法，但是最好還是保持例項域的私有性。很多慘痛的經驗告訴我們，資料的表示形式很可能會改變，但它們的使用方式卻不會經常發生變化。當資料保持私有時，它們的表示形式的變化不會對類的使用者產生影響，即使出現bug也易於檢測。
2)一定要對資料初始化。
Java不對區域性變數進行初始化，但是會對物件的例項域進行初始化。最好不要依賴於系統的預設值，而是應該顯式地初始化所有的資料，具體的初始化方式可以是提供預設值，也可以是在所有構造器中設定預設值。
3)不要在類中使用過多的基本資料型別。
就是說，用其他的類代替多個相關的基本資料型別的使用。這樣會使類更加易於理解且易於修改。例如，用一個稱為Address的新的類替換下面的Customer類中的例項域：
private String street;
private String city;
private String state;
private int zip;
這樣，可以很容易地順應地址的變化，例如，需要增加對國際地址的處理。
4)不是所有的域都需要獨立的域訪問器和域更改器。
或許，需要獲得或設定僱員的薪金。而一旦構造了僱員物件，就應該禁止更改僱用日期，並且在物件中，常常包含一些不希望別人獲得或設定的'例項域，例如，在Address類中，存放州縮寫的陣列。
5)使用標準格式進行類的定義。
一定採用下面的順序書寫類的內容：
公有訪問特性部分
包作用域訪問特性部分
私有訪問特性部分
在每一部分中，應該按照下列順序列出：
例項方法
靜態方法
例項域
靜態域
畢竟，類的使用者對公有介面要比對私有的實現細節更感興趣，並且對方法要比對資料更感興趣。
但是，哪一種風格更好並沒有達成共識。Sun的程式設計風格建議Java程式設計語言先書寫域，後書寫方法。無論採用哪種風格，重要的一點是要保持一致。
6)將職責過多的類進行分解。
這樣說似乎有點含糊不清，究竟多少算是"過多"?每個人的看法不同。但是，如果明顯地可以將一個複雜的類分解成兩個更為簡單的類，就應該將其分解(但另一方面，也不要走極端。設計10個類，每個類只有一個方法，顯然也太小了)。
下面是一個反面的設計示例。
public class CardDeck// bad design
{
public CardDeck(){…}
public void shuffile(){…}
public void draw(){…}
public int getTopValue(){}
public int getTopSuit(){}
private int[] value;
private int[] suit;
}
實際上，這個類實現了兩個獨立的概念：一副牌(含有shuffle方法和draw方法)和一張牌(含有檢視面值和花色的方法)。另外，引入一個表示單張牌的Card類。現在有兩個類，每個類完成自己的職責：
public class CardDeck// better design
{
public CardDeck(){…}
public void shuffile(){…}
public void draw(){…}
public int getTopValue(){}
public int getTopSuit(){}
private Card[] cards;
}
public class Card {
public Card(int value,int aSuit){}
public int getTopValue(){}
public int getTopSuit(){}
private int value;
private int suit;
}
7)類名和方法名要能夠體現它們的職責。
與變數應該有一個能夠反映其含義的名字一樣，類也應該如此(在標準類庫中，也存在著一些含義不明確的例子，如：Date類實際上是一個用於描述時間的類)。
命名類名的良好習慣是採用一個名詞(Order)、前面有形容詞修飾的名詞(RushOrder)或動名詞(有"-ing"字尾)修飾名詞(例如，BillingAddress)。對於方法來說，習慣是訪問器方法用小寫get開頭(getSalary)，更改器方法用小寫的set開頭(setSalary)。
