(
) 類名首字母應該大寫
字段
方法以及對象（句柄）的首字母應小寫
對於所有標識符
其中包含的所有單詞都應緊靠在一起
而且大寫中間單詞的首字母
例如
ThisIsAClassName
thisIsMethodOrFieldName
若在定義中出現了常數初始化字符
則大寫static final基本類型標識符中的所有字母
這樣便可標志出它們屬於編譯期的常數
Java包（Package）屬於一種特殊情況
它們全都是小寫字母
即便中間的單詞亦是如此
對於域名擴展名稱
如com
org
net或者edu等
全部都應小寫（這也是Java
和Java
的區別之一）
(
) 為了常規用途而創建一個類時
請采取
經典形式
並包含對下述元素的定義
equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable
(
) 對於自己創建的每一個類
都考慮置入一個main()
其中包含了用於測試那個類的代碼
為使用一個項目中的類
我們沒必要刪除測試代碼
若進行了任何形式的改動
可方便地返回測試
這些代碼也可作為如何使用類的一個示例使用
(
) 應將方法設計成簡要的
功能性單元
用它描述和實現一個不連續的類接口部分
理想情況下
方法應簡明扼要
若長度很大
可考慮通過某種方式將其分割成較短的幾個方法
這樣做也便於類內代碼的重復使用（有些時候
方法必須非常大
但它們仍應只做同樣的一件事情）
(
) 設計一個類時
請設身處地為客戶程序員考慮一下（類的使用方法應該是非常明確的）
然後
再設身處地為管理代碼的人考慮一下（預計有可能進行哪些形式的修改
想想用什麼方法可把它們變得更簡單）
(
) 使類盡可能短小精悍
而且只解決一個特定的問題
下面是對類設計的一些建議
■一個復雜的開關語句
考慮采用
多形
機制
■數量眾多的方法涉及到類型差別極大的操作
考慮用幾個類來分別實現
■許多成員變量在特征上有很大的差別
考慮使用幾個類
(
) 讓一切東西都盡可能地
私有
——private
可使庫的某一部分
公共化
（一個方法
類或者一個字段等等）
就永遠不能把它拿出
若強行拿出
就可能破壞其他人現有的代碼
使他們不得不重新編寫和設計
若只公布自己必須公布的
就可放心大膽地改變其他任何東西
在多線程環境中
隱私是特別重要的一個因素——只有private字段才能在非同步使用的情況下受到保護
(
) 謹惕
巨大對象綜合症
對一些習慣於順序編程思維
且初涉OOP領域的新手
往往喜歡先寫一個順序執行的程序
再把它嵌入一個或兩個巨大的對象裡
根據編程原理
對象表達的應該是應用程序的概念
而非應用程序本身
(
) 若不得已進行一些不太雅觀的編程
至少應該把那些代碼置於一個類的內部
(
) 任何時候只要發現類與類之間結合得非常緊密
就需要考慮是否采用內部類
從而改善編碼及維護工作（參見第
章
小節的
用內部類改進代碼
）
(
) 盡可能細致地加上注釋
並用javadoc注釋文檔語法生成自己的程序文檔
(
) 避免使用
魔術數字
這些數字很難與代碼很好地配合
如以後需要修改它
無疑會成為一場噩夢
因為根本不知道
到底是指
數組大小
還是
其他全然不同的東西
所以
我們應創建一個常數
並為其使用具有說服力的描述性名稱
並在整個程序中都采用常數標識符
這樣可使程序更易理解以及更易維護
(
) 涉及構建器和異常的時候
通常希望重新丟棄在構建器中捕獲的任何異常——如果它造成了那個對象的創建失敗
這樣一來
調用者就不會以為那個對象已正確地創建
從而盲目地繼續
(
) 當客戶程序員用完對象以後
若你的類要求進行任何清除工作
可考慮將清除代碼置於一個良好定義的方法裡
采用類似於cleanup()這樣的名字
明確表明自己的用途
除此以外
可在類內放置一個boolean（布爾）標記
指出對象是否已被清除
在類的finalize()方法裡
請確定對象已被清除
並已丟棄了從RuntimeException繼承的一個類（如果還沒有的話）
從而指出一個編程錯誤
在采取象這樣的方案之前
請確定finalize()能夠在自己的系統中工作（可能需要調用System
runFinalizersOnExit(true)
從而確保這一行為）
(
) 在一個特定的作用域內
若一個對象必須清除（非由垃圾收集機制處理）
請采用下述方法
初始化對象
若成功
則立即進入一個含有finally從句的try塊
開始清除工作
(
) 若在初始化過程中需要覆蓋（取消）finalize()
請記住調用super
finalize()（若Object屬於我們的直接超類
則無此必要）
在對finalize()進行覆蓋的過程中
對super
finalize()的調用應屬於最後一個行動
而不應是第一個行動
這樣可確保在需要基礎類組件的時候它們依然有效
(
) 創建大小固定的對象集合時
請將它們傳輸至一個數組（若准備從一個方法裡返回這個集合
更應如此操作）
這樣一來
我們就可享受到數組在編譯期進行類型檢查的好處
此外
為使用它們
數組的接收者也許並不需要將對象
造型
到數組裡
(
) 盡量使用interfaces
不要使用abstract類
若已知某樣東西准備成為一個基礎類
那麼第一個選擇應是將其變成一個interface（接口）
只有在不得不使用方法定義或者成員變量的時候
才需要將其變成一個abstract（抽象）類
接口主要描述了客戶希望做什麼事情
而一個類則致力於（或允許）具體的實施細節
(
) 在構建器內部
只進行那些將對象設為正確狀態所需的工作
盡可能地避免調用其他方法
因為那些方法可能被其他人覆蓋或取消
從而在構建過程中產生不可預知的結果（參見第
章的詳細說明）
(
) 對象不應只是簡單地容納一些數據
它們的行為也應得到良好的定義
(
) 在現成類的基礎上創建新類時
請首先選擇
新建
或
創作
只有自己的設計要求必須繼承時
才應考慮這方面的問題
若在本來允許新建的場合使用了繼承
則整個設計會變得沒有必要地復雜
(
) 用繼承及方法覆蓋來表示行為間的差異
而用字段表示狀態間的區別
一個非常極端的例子是通過對不同類的繼承來表示顏色
這是絕對應該避免的
應直接使用一個
顏色
字段
(
) 為避免編程時遇到麻煩
請保證在自己類路徑指到的任何地方
每個名字都僅對應一個類
否則
編譯器可能先找到同名的另一個類
並報告出錯消息
若懷疑自己碰到了類路徑問題
請試試在類路徑的每一個起點
搜索一下同名的
class文件
(
) 在Java
AWT中使用事件
適配器
時
特別容易碰到一個陷阱
若覆蓋了某個適配器方法
同時拼寫方法沒有特別講究
最後的結果就是新添加一個方法
而不是覆蓋現成方法
然而
由於這樣做是完全合法的
所以不會從編譯器或運行期系統獲得任何出錯提示——只不過代碼的工作就變得不正常了
(
) 用合理的設計方案消除
偽功能
也就是說
假若只需要創建類的一個對象
就不要提前限制自己使用應用程序
並加上一條
只生成其中一個
注釋
請考慮將其封裝成一個
獨生子
的形式
若在主程序裡有大量散亂的代碼
用於創建自己的對象
請考慮采納一種創造性的方案
將些代碼封裝起來
(
) 警惕
分析癱瘓
請記住
無論如何都要提前了解整個項目的狀況
再去考察其中的細節
由於把握了全局
可快速認識自己未知的一些因素
防止在考察細節的時候陷入
死邏輯
中
(
) 警惕
過早優化
首先讓它運行起來
再考慮變得更快——但只有在自己必須這樣做
而且經證實在某部分代碼中的確存在一個性能瓶頸的時候
才應進行優化
除非用專門的工具分析瓶頸
否則很有可能是在浪費自己的時間
性能提升的隱含代價是自己的代碼變得難於理解
而且難於維護
(
) 請記住
閱讀代碼的時間比寫代碼的時間多得多
思路清晰的設計可獲得易於理解的程序
但注釋
細致的解釋以及一些示例往往具有不可估量的價值
無論對你自己
還是對後來的人
它們都是相當重要的
如對此仍有懷疑
那麼請試想自己試圖從聯機Java文檔裡找出有用信息時碰到的挫折
這樣或許能將你說服
(
) 如認為自己已進行了良好的分析
設計或者實施
那麼請稍微更換一下思維角度
試試邀請一些外來人士——並不一定是專家
但可以是來自本公司其他部門的人
請他們用完全新鮮的眼光考察你的工作
看看是否能找出你一度熟視無睹的問題
采取這種方式
往往能在最適合修改的階段找出一些關鍵性的問題
避免產品發行後再解決問題而造成的金錢及精力方面的損失
(
) 良好的設計能帶來最大的回報
簡言之
對於一個特定的問題
通常會花較長的時間才能找到一種最恰當的解決方案
但一旦找到了正確的方法
以後的工作就輕松多了
再也不用經歷數小時
數天或者數月的痛苦掙扎
我們的努力工作會帶來最大的回報（甚至無可估量）
而且由於自己傾注了大量心血
最終獲得一個出色的設計方案
成功的快感也是令人心動的
堅持抵制草草完工的誘惑——那樣做往往得不償失
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19247.html
