最近感覺技術書籍讀太少了. 決定把 Effective Java 翻出來再讀一遍. 以下主要是摘錄, 不過也夾雜著我的一些私貨, 私貨會用斜體標出.
Chapter 2 Creating and Destroying Objects
Item 1 Consider static factory methods instead of constructors
用靜態工廠方法替代構造函數, 這個應該是一個比較公認的原則.
使用靜態工廠方法的優點有
- 靜態工廠方法是有名字的. 一個合理的名字會大大提高代碼的可讀性. 還可以避免兩個不同構造函數, 但是參數類型完全一樣的尷尬情況.
- 不像構造函數, 靜態工廠函數并不要求每次都需要創建一個新的對象. 像 Singleton, Immutable Class 等都依賴于此.
- 靜態工廠函數可以返回類的子類. 可以隱藏具體的實現. 比如根據手機中的系統版本返回不同的對象. 甚至可以返回編寫時并不在的子類. 編寫 Service 時十分方便.
-
可以避免重復寫類型參數. 這條并沒有時效性, 在 Java 7 里 Java 的類型推導功能得到了強化, 已經不需要在創建的時候重復寫類型參數了.
靜態工廠方法的缺點有:
只有靜態工廠的方法的類無法繼承. 雖然現代的面向對象的思想都是鼓勵使用組合替代繼承. 但是不可否認在很多時候繼承還是很有用的.
靜態工廠方法跟普通的靜態方法是一樣的. 不過這個可以用特殊的命名規則來區分. 常見的命名有: valueOf, of, getInstance, newInstance 等.
*如何給工廠命名也是一件很麻煩的事. 雖然書中提到了 newInstance 這樣的命名方式. 但是我十分不喜歡 newInstance 這個名字, 因為 newInstance 跟普通的構造函數相比沒有提供任何額外信息. *
Item 2: Consider a builder when faced with many constructor parameters
當對象的構造函數需要的參數比較多, 特別是很多參數是同樣類型的時候特別適合使用 Builder. 在實際工作中也使用得特別廣泛.
但是 Builder 十分冗余和機械, 寫起來相當無聊. 之所以需要出現完全是為彌補 Java 的缺少的特性. 如果一門語言可以提供默認參數和命名參數的功能, 完全不需要 Builder 模式. 比如 Kotlin 中可以寫這樣的代碼:
class NutritionFacts(val servingSize: Int,
val servings: Int,
val calories: Int = 0,
val fat: Int = 0,
val sodium: Int = 0,
val carbohydrate: Int = 0) {
}
fun main(args: Array<String>) {
NutritionFacts(servingSize = 240,
servings = 8,
calories = 100,
sodium = 35,
carbohydrate = 27)
}
效果和 Builder 一模一樣. Swift 也提供同樣的功能, Swift 3 中的參數名甚至已經變成強制的了. 當然如果濫用這兩個特性也會帶來很多的問題, 但是我覺得保證正確使用語言的提供的特性(Best Practice)是開發者需要做的事. 自己用不好, 不能怪語言.
Item 3 Enforce the singleton property with a private constructor or an enum type
介紹了幾種創建 Singleton 的方式, enum 是最好的單例模式.
public enum Elvis {
INSTANCE;
//....
}
單例在 Java/Android 程序中十分常見, 也十分方便和強大. 但是單例其實可以認為是一個全局變量, 如非必要, 不要濫用. 比如在 Android 當中, 如果一個對象會持有 context, 那么就不適合做單例, 可能會引發內存的泄漏.
Item 4 Enforce noninstantiability with a private constructor
通過把工具類的構造函數變成私有的來避免被創建.
Item 5 Avoid Creating Unnecessary Objects
避免重復創建沒有必要的對象. 一些對象的創建代價是比較大, 比如 Calendar 和 Pattern, 對于這種類型的對象就要小心翼翼, 避免沒有必要的創建.
這一條是針對創建代價大的對象. 現代的 JVM 對小對象的創建和銷毀都有特別的優化. 不要刻意去采用如對象池之類的方式去避免創建對象和重用對象. 一切優化應該以性能測試的結果為標準.
Item 6 Eliminate obsolete object references
及時清楚過時的對象. Java 有 GC 功能避免很內存泄漏的問題, 但是因為 GC 的原因使得內存泄漏也變得更加隱秘. 書里提到的三種常見的內存泄漏的原因:
- 該類由自己管理內存. 比如書里提到的 Stack 類.
- Cache, Cache 最好使用 Weak Reference 或者 Soft Reference. 個人感覺 Soft Reference 會更適合 Cache
- Listener 和 Callback. 主要是 register 和 unregister 不配對造成的. 這里推薦使用 Weak Reference.
*實際上 Android 中 View 的Listener 并不是用 Weak Reference 的, 因為很常見的用法是 Activity 持有 Listener 和 View, 然后一旦 Activity 的回收, View 和 Listener 會一起被回收. *
在我司的應用中也大量使用了 Observer 模式, 而且有一些 Model 在整個程序的生命周期當中都是存在的. 對于這些 Model 的 regsiter 和 unregister 必須要求配對, 否則就會產生內存泄漏. 也曾經考慮過采用 Weak Reference 方案, 最終沒有采用. 主要原因有兩點:
- 采用了 Weak Reference, 就必須要保證 Observer 有一個額外的引用. 并沒有降低太多的復雜度
- 采用 Weak Reference 雖然避免了內存泄漏, 但是卻會掩蓋編碼不規范的問題.
Item 7 Avoid finalizer
使用 Finalizer 的缺點
- Finalize 方法沒有保證會被及時調用.
- Finalize 方法設置沒有保證會被調用.
- Finalizer 中如果產生異常, 對象的回收過程會中斷, 但是異常會被直接忽略. 會造成不確定的 bug.
- finalizer 會對性能造成影響.
使用 Finalizer 的場景
在兩種情況下可以使用 Finalizer, 但是要非常小心:
- 作為一個 Safety Net. 在忘記顯式地調用對象的結束函數時做一個補救.
- 用于釋放 Native Peer 對象中的 Natvie 資源. 但是如果該資源不能是一個關鍵資源而且該資源不要求及時釋放.
替代方案
不能使用 Finalizer, 對于需要使用 finalize 的場景就應該提供顯式結束函數, 然后由開發者顯式地調用. 比如 InputStream 的 close.
