簡單的介紹幾點技巧，應用這些技巧可以使得設計出來的類更具有OOP的專業水準。
(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個類，每一個類只用一個方法，顯然也太小了。）
(7)類名和方法名要能夠體現它們的職責
與變量應該有一個能夠反映其含義的名字一樣,類名也應該如此.
命名類名的良好習慣是采用一個名詞(Order)、前面有形容詞修飾的名詞(RushOrder)或動名詞（有-ing后綴）修飾名詞（例如，BillingAddress）。對方法來說，習慣是訪問器方法用小寫get開頭，更改器方法用小寫set開頭。