JAVA程式設計規則:

天下有賊發表於2005-11-29
Java程式設計
JAVA程式設計規則:
(1) 類名首字母應該大寫。欄位、方法以及物件（控制程式碼）的首字母應小寫。對於所有識別符號，其中包含
    的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如：
        ThisIsAClassName
        thisIsMethodOrFieldName
   若在定義中出現了常數初始化字元，則大寫static final基本型別識別符號中的所有字母。這樣便可標誌出它們屬於編譯期的常數。
   Java包（Package）屬於一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對於域名副檔名稱，如com，org，net或者edu等，全部都應小寫（這也是Java 1.1和Java 1.2的區別之一）。

(2) 為了常規用途而建立一個類時，請採取“經典形式”，幷包含對下述元素的定義：

    equals()
    hashCode()
    toString()
    clone()（implement Cloneable）
    implement Serializable

(3) 對於自己建立的每一個類，都考慮置入一個main()，其中包含了用於測試那個類的程式碼。為使用一
    個專案中的類，我們沒必要刪除測試程式碼。若進行了任何形式的改動，可方便地返回測試。這些代
    碼也可作為如何使用類的一個示例使用。

(4) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類介面部分。理想情況下，方
    法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便於類內
   程式碼的重複使用（有些時候，方法必須非常大，但它們仍應只做同樣的一件事情）。

(5) 設計一個類時，請設身處地為客戶程式設計師考慮一下（類的使用方法應該是非常明確的）。然後，再
    設身處地為管理程式碼的人考慮一下（預計有可能進行哪些形式的修改，想想用什麼方法可把它們變
    得更簡單）。
(6) 使類儘可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
    ■一個複雜的開關語句：考慮採用“多形”機制
    ■數量眾多的方法涉及到型別差別極大的操作：考慮用幾個類來分別實現
    ■許多成員變數在特徵上有很大的差別：考慮使用幾個類

(7) 讓一切東西都儘可能地“私有”——private。可使庫的某一部分“公共化”（一個方法、類或者一
    個欄位等等），就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的程式碼，使他們不得不
    重新編寫和設計。若只公佈自己必須公佈的，就可放心大膽地改變其他任何東西。在多執行緒環境中，
    隱私是特別重要的一個因素——只有private欄位才能在非同步使用的情況下受到保護。

(8) 謹惕“巨大物件綜合症”。對一些習慣於順序程式設計思維、且初涉OOP領域的新手，往往喜歡先寫一個
   順序執行的程式，再把它嵌入一個或兩個巨大的物件裡。根據程式設計原理，物件表達的應該是應用程式
   的概念，而非應用程式本身。

(9) 若不得已進行一些不太雅觀的程式設計，至少應該把那些程式碼置於一個類的內部。

(10) 任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否採用內部類，從而改善編碼及維護
    工作（參見第14章14.1.2小節的“用內部類改進程式碼”）。

(11) 儘可能細緻地加上註釋，並用javadoc註釋文件語法生成自己的程式文件。

(12) 避免使用“魔術數字”，這些數字很難與程式碼很好地配合。如以後需要修改它，無疑會成為一場噩
     夢，因為根本不知道“100”到底是指“陣列大小”還是“其他全然不同的東西”。所以，我們應
    建立一個常數，併為其使用具有說服力的描述性名稱，並在整個程式中都採用常數識別符號。這樣可
    使程式更易理解以及更易維護。

(13) 涉及構建器和異常的時候，通常希望重新丟棄在構建器中捕獲的任何異常——如果它造成了那個對
    象的建立失敗。這樣一來，呼叫者就不會以為那個物件已正確地建立，從而盲目地繼續。

(14) 當客戶程式設計師用完物件以後，若你的類要求進行任何清除工作，可考慮將清除程式碼置於一個良好定
    義的方法裡，採用類似於cleanup()這樣的名字，明確表明自己的用途。除此以外，可在類內放置
    一個boolean（布林）標記，指出物件是否已被清除。在類的finalize()方法裡，請確定物件已被
    清除，並已丟棄了從RuntimeException繼承的一個類（如果還沒有的話），從而指出一個程式設計錯誤。
    在採取象這樣的方案之前，請確定finalize()能夠在自己的系統中工作（
    可能需要呼叫System.runFinalizersOnExit(true)，從而確保這一行為）。

(15) 在一個特定的作用域內，若一個物件必須清除（非由垃圾收集機制處理），請採用下述方法：初始
    化物件；若成功，則立即進入一個含有finally從句的try塊，開始清除工作。

(16) 若在初始化過程中需要覆蓋（取消）finalize()，請記住呼叫super.finalize()（若Object屬於我
     們的直接超類，則無此必要）。在對finalize()進行覆蓋的過程中，對super.finalize()的呼叫應
     屬於最後一個行動，而不應是第一個行動，這樣可確保在需要基礎類元件的時候它們依然有效。

(17) 建立大小固定的物件集合時，請將它們傳輸至一個陣列（若準備從一個方法裡返回這個集合，更應
     如此操作）。這樣一來，我們就可享受到陣列在編譯期進行型別檢查的好處。此外，為使用它們，
     陣列的接收者也許並不需要將物件“造型”到陣列裡。

(18) 儘量使用interfaces，不要使用abstract類。若已知某樣東西準備成為一個基礎類，那麼第一個選
     擇應是將其變成一個interface（介面）。只有在不得不使用方法定義或者成員變數的時候，才需
    要將其變成一個abstract（抽象）類。介面主要描述了客戶希望做什麼事情，而一個類則致力於
   （或允許）具體的實施細節。

(19) 在構建器內部，只進行那些將物件設為正確狀態所需的工作。儘可能地避免呼叫其他方法，因為那
    些方法可能被其他人覆蓋或取消，從而在構建過程中產生不可預知的結果（參見第7章的詳細說
    明）。

(20) 物件不應只是簡單地容納一些資料；它們的行為也應得到良好的定義。

(21) 在現成類的基礎上建立新類時，請首先選擇“新建”或“創作”。只有自己的設計要求必須繼承時
     ，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復
   雜。

(22) 用繼承及方法覆蓋來表示行為間的差異，而用欄位表示狀態間的區別。一個非常極端的例子是通過
    對不同類的繼承來表示顏色，這是絕對應該避免的：應直接使用一個“顏色”欄位。

(23) 為避免程式設計時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，
     編譯器可能先找到同名的另一個類，並報告出錯訊息。若懷疑自己碰到了類路徑問題，請試試在類
      路徑的每一個起點，搜尋一下同名的.class檔案。

(24) 在Java 1.1 AWT中使用事件“介面卡”時，特別容易碰到一個陷阱。若覆蓋了某個介面卡方法，同
    時拼寫方法沒有特別講究，最後的結果就是新新增一個方法，而不是覆蓋現成方法。然而，由於這
    樣做是完全合法的，所以不會從編譯器或執行期系統獲得任何出錯提示——只不過程式碼的工作就變
    得不正常了。

(25) 用合理的設計方案消除“偽功能”。也就是說，假若只需要建立類的一個物件，就不要提前限制
   自己使用應用程式，並加上一條“只生成其中一個”註釋。請考慮將其封裝成一個“獨生子”的形式
  。若在主程式裡有大量散亂的程式碼，用於建立自己的物件，請考慮採納一種創造性的方案，將些程式碼
   封裝起來。

(26) 警惕“分析癱瘓”。請記住，無論如何都要提前瞭解整個專案的狀況，再去考察其中的細節。由於
    把握了全域性，可快速認識自己未知的一些因素，防止在考察細節的時候陷入“死邏輯”中。

(27) 警惕“過早優化”。首先讓它執行起來，再考慮變得更快——但只有在自己必須這樣做、而且經證
    實在某部分程式碼中的確存在一個效能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否
   則很有可能是在浪費自己的時間。效能提升的隱含代價是自己的程式碼變得難於理解，而且難於維護。

(28) 請記住，閱讀程式碼的時間比寫程式碼的時間多得多。思路清晰的設計可獲得易於理解的程式，但註釋
  、細緻的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對後來的人，它們都是相
   當重要的。如對此仍有懷疑，那麼請試想自己試圖從聯機Java文件裡找出有用資訊時碰到的挫折，
   這樣或許能將你說服。

(29) 如認為自己已進行了良好的分析、設計或者實施，那麼請稍微更換一下思維角度。試試邀請一些外
  來人士——並不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的
  工作，看看是否能找出你一度熟視無睹的問題。採取這種方式，往往能在最適合修改的階段找出一些
  關鍵性的問題，避免產品發行後再解決問題而造成的金錢及精力方面的損失。

(30) 良好的設計能帶來最大的回報。簡言之，對於一個特定的問題，通常會花較長的時間才能找到一種
     最恰當的解決方案。但一旦找到了正確的方法，以後的工作就輕鬆多了，再也不用經歷數小時、數天
     或者數月的痛苦掙扎。我們的努力工作會帶來最大的回報（甚至無可估量）。而且由於自己傾注了
     大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑
      ——那樣做往往得不償失。

(31) 可在Web上找到大量的程式設計參考資源，甚至包括大量新聞組、討論組、郵寄列表等。下面這個地方
    提供了大量有益的連結：

相關文章