EffectiveJava筆記

1.考慮用靜態工廠方法代替構造函數(Integer.valueOf(),Boolean.valueOf())
    1.靜態方法有方法名進行分辨
    2.靜態方法不必定非要新建一個對象,new 方法確定會新建對象
    3.能夠返回子類對象(?)
    1b.
    2b.與其餘靜態方法沒有區別
2.私有構造函數強化單例
3.私有構造函數防止被實例化或子類實例化
4.避免建立重複對象:如String s=new String("Hello world");//不推薦
5.消除過時的引用對象:手動ref=null以釋放資源，適用於數組
6.避免使用終結函數finalize()，java自動垃圾回收比人爲回收資源穩定
/////對象
7.重寫equals()時遵照標準
8.重寫equals()時順便把hashCode()也重重寫了
9.建議重寫toString()
10.謹慎重寫clone():複雜度過高了,儘量不重寫而是提供其餘拷貝方法
11.實現Compareable接口:值類都應該這樣，方便排序什麼的,compareTo()不用判斷時參是否爲null
///////類和接口
12.使類和成員的可訪問能力最最小話:private default protected public
13.支持不可變性
14.複合優先於繼承:與其實現父類的方法，不如將父類型做爲子類的一個屬性進行轉發操做
    這樣能夠防止父類接口方法的變更影響子類，也叫「包裝類」，不能用在回調框架上，
    最好不要支持鏈式編程
15.要麼專門爲繼承而設計，並給出詳細的文檔說明，要麼禁止繼承：
    繼承爲了方便實現，可考慮鉤子函數的使用
    子類構造函數不能調用可重載(override)的函數
    clone()和readObject也不能調用可重載的任何方法，他們跟構造函數差很少
    若是必須繼承，確保沒有自調用方法
16.接口因爲抽象類：java單繼承機制使抽象類很差用
    接口方便子類的功能擴展
    能夠考慮一個接口骨架子類實現大部分相關操做如:AbstractXXX.class
17.接口僅限於定義類型：
    爲了常量而實現一個接口不明智，反而是污染
18.優先考慮靜態成員類：
    靜態內部類佔用更少的內存(內部類不訪問外部類屬性的狀況下)
///////C語言替代
19.用類代替結構
///////方法
23.檢查參數的有效性
24.必要時使用保護性拷貝
25.謹慎設計方法的原型:接口方法明具有必定的類似
    參數通常3個左右便可
    用類攜帶參數，以減小參數數量
    儘可能使用接口做爲參數，而不是實現類
26.謹慎重載方法：overload不是override(覆蓋)
    避免參數數目相同的重載方法
27.返回零長度的數組而不是null
28.爲全部導出的公開API寫註釋文檔
//////////第7章：通用程序設計
29.將局部變量的做用域最小化
30.瞭解和使用庫
31.若是要求高精度的結果，避免使用float和doubel:BigDecimal更精確
32.若是有其餘類型適合，儘可能避免String:
    值類型就用值類型
    字符串不適合代替枚舉
33.瞭解字符串鏈接的性能：String是值不變類，值永遠不變，StringBuilder，StringBuffer
34.經過接口引用對象：參考25，頂層父類代替子類做爲引用對象
35.接口比反射優先:反射會丟失編譯檢查的好處，反射性能廣泛較低
36.謹慎使用本地方法JNI：JVM(JDK1.3以後)發展到如今，性能已經能夠匹敵本地其餘語言方法了
37.謹慎優化：一句話，不要優化，尤爲是不成熟的優化
    努力編寫好的程序而不是快的程序
    努力避免那些限制性能的設計決定，API，數據格式等
    優化後記得測試性能
38.遵照廣泛接受的命名規範
////////第8章：異常
39.只針對不正常的條件使用異常：隨便使用異常只會犧牲性能
    狀態測試如hasNext()比較好
    儘可能不強迫API使用者使用異常
40.對於可恢復的條件使用被檢查的異常，對於程序錯誤使用運行時異常
41.儘可能不要拋出多餘的異常：麻煩
    若是異常較少的話還不如不拋，能夠考慮轉換成boolean
42.儘可能使用標準異常
43.拋出的異常要合適於相應的抽象
    異常捕獲與轉換
44.每一個拋出的異常都要有文檔
45.在細節中包含失敗，捕獲信息
46.努力使失敗保持原子型
    儘可能檢查參數的有效性
    在拷貝上操做，完成再複製
47.不要忽略異常
///////////第9章：線程

//////////第10章：序列化
54.謹慎使用Serializable
    序列化開銷很大
    爲了繼承而設計的類應儘可能不要實現序列化接口：抽象類不能實例化等因素
55.儘量本身設計序列化形勢
    若是不肯定是否須要使用默認的序列化形勢，則不要使用默認序列化
    若是一個對象的物理表示等同於它的邏輯內容，能夠考慮默認序列化形式
    默認序列化儘可能提供readObject()實現約束
56.保護性的實現readObject()
57.必要時提供一個readResolve()
    
總結:不讀這本樹一樣能夠寫出程序，可是讀這本書可讓java開發有更好更實用的開發技巧，書不講基礎知識，所以不適合初學者，相反，寫代碼的時間越長讀這本樹感悟越多，並且，隨着工做經驗越長，對書的內容理解越深，適合長期收藏的書。