Effective Java 筆記（十）

相關讀書筆記列表

第38條：遵守普遍接受的命名慣例

java的命名慣例分為兩大類：字面的和文法的。
字面命名慣例涉及包、類、介面、方法和域。
    包的名字是階層的，用句號分隔第一部分。每一部分的長度不要超過8，由小寫字母和數字組成（數字少見用），鼓勵使用有意義的縮寫。除了java和javax外，一般以網域名稱做開頭，順序是頂級網域名稱放在最前面。
    類和介面的名字應至少1至多個單詞，每個單詞的首字母大寫（駝峰試)，盡量避免縮寫。

方法和域的名字與類和介面的名字遵守相同的字面慣例，只是第一個首字母要小寫。常量域要全部字母都大寫，詞之間通過底線區分。

文法命名慣例比字面慣例更靈活。

1. 類通常用一個名詞或名詞短語，介面或者與類相同，或者以"-able"或"-ible"結尾的形容詞。
2. 執行某個動作的方法，常用一個動詞或動詞短語，
3. 對於返回boolean類型的方法，名字常以“is"開頭後加一個名詞或形容詞或短語，
4. 如果返回的不是boolean，則常用一個名詞/短語，或以"get"開頭的動詞短語。
5. 如果一方法所在的類是一個Bean，則強制要求以get開頭。
6. 如果類包含對屬性操作，常用setAttribute或getAttribute格式命名。

轉換物件類型的方法，

1. 如果返回不同類型的獨立的對象，則稱為toType
2. 如果返回一個視圖，則用asType,
3. 如果返回與被調用對象同值的原語類型，稱為typeValue
4. 靜態工廠的方法，常用valueOf或getInstance.

 

NO.39 只針對不正常的條件才使用異常

異常只應該被用於不正常的條件，它們永遠不應被用於正常的控制流程。

下面是一個用異常作遍曆結束條件的濫用異常的例子：
//horrible abuse of exceptions. Don't ever do this!<br />try{<br /> int i=0;<br /> while(true)a[i++].f();<br />}catch(ArrayIndexOutOfBoundsException e){<br /> ...<br />}

其錯有三：

1、建立、拋出和捕獲異常的開銷是很昂貴的。因為它的初衷是用於不正常的情形，少有jvm會它進行效能最佳化。

2、把代碼放在try-catch中會阻止jvm實現本來可能要執行的某些特定的最佳化。

3、有些現代的jvm對迴圈進行最佳化，不會出現冗餘的檢查。

完全可以使用標準的實現方式：

for(int i=0;i<a.length;i++){<br /> a[i].f();<br />}

　　這條原則也適用於API設計。一個設計良好的API不應該強迫它的客戶為了正常的控制流程而使用異常。如果類中有一個”狀態相關”的方法，即只有
特定的條件下可被調用的方法，則這個類也應有一個單獨的“狀態測試”方法，以為調用這個狀態相關方法前的檢查。如Collection類的next方法和
hasNext方法。
for(Iterator i=collection.iterator();i.hasNext();){<br /> Foo foo=(Foo)i.next();<br /> ...<br />} 

第40條：對於可恢複的條件使用被檢查的異常，對於程式錯誤使用運行時異常

   
java提供了三種可拋出的異常：被檢查的異常（checkedException）、運行時異常（run-time Exception）和錯誤(error)。
　　如果期望調用者在調用時出現的異常能夠恢複，則應該使用被檢查的異常，通過拋出一個被檢查的異常，強迫調用者在catch中處理該異常，或者將異常傳播到外面。

　　對於一個方法聲明要拋出的每一個被檢查的異常，它是對API使用者的一種潛在指示：與異常相關聯的條件是調用這次個方法的一種可能結果。

　
　兩種未被檢查的可拋出結構：運行時異常和錯誤，在行為上相同的，它們都不需要、也不應該被捕獲的拋出物。你所實現的所有未被檢查的拋出結構都應是
RuntimeException的子類。定義一個非Exception、RuntimeException或Error子類的拋出物是可行的，但從行為
意義上它等同於被普通的被檢查異常（即Exception子類而非RuntimeException子類）.

　　異常是個完全意義上的對象，在其上可以定義任意的方法。因被檢查的異常往往指示了可恢複的條件，所以可通過定義方法，使調用者可獲得一些有助於恢複的資訊。具體可參見“Java異常的分類”

NO.41 避免不必要地使用被檢查的異常

    與傳回碼不同，被檢查的異常強迫程式處理例外的情況，從而大大地提高了程式的可靠性。而過分地使用被檢查的異常，則增加了不可忽視的負擔。如果正
確地使用API並不能阻止這種異常條件的產生，並且一旦產生了異常，使用API的程式可以採取有用的動作，那麼這種負擔被認為是正當的。
try{<br /> ...<br />}catch(TheCheckedException e){<br /> e.printStackTree();<br /> System.exit(1);<br />}

　　如果使用API的程式員無法做得比這更好，那麼未被檢查的異常可能更為合適。在實踐中，catch幾乎總有宣告失敗的特徵。

　　“把被檢查的異常變成未被檢查的異常”的一種技術是，把這個要拋出異常的方法分成兩個方法，第一個方法返回一個boolean以指明是否要拋出異常，另一個執行真正的功能，如果條件不滿足就拋異常。如下：
//Invocation with checked exception<br />try{<br /> obj.action(args);<br />}catch(TheCheckedException e){<br /> //Handle exception condition<br />}

　　轉換為：
//Invocation with state-testing method and unchecked exception<br />if(obj.actionPermitted(args)){<br /> obj.action(args));<br />}else{<br /> //handle exception condition<br />}

　　當然這種轉換並不總是合適的，例如一對象將在缺少外部同步的情況下被並發訪問，或者可被外界改變狀態，那麼這種轉換將是不合適的。