最近感觉技术书籍读太少了. 决定把 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.
