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