《Effective Java》Java名著,必讀。如果能嚴格遵從本文的原則,以編寫API的質量來苛求自己的代碼,會大大提升編碼素質。
以下內容只記錄了我自己整理的東西,還是建議讀原文。爲了聚焦知識點,一些說明故意忽略掉了。相當於是一篇摘要。
1、考慮用靜態工廠方法替代構造函數
例子:
Integer.valueOf(“1”)、Boolean.valueOf(“true”)等。
優勢:
- 可讀性高(方法名)
- 性能(不一定創建對象)
- 靈活性高
下面針對三個優勢進行一些解讀。
可讀性高
new Point(x,y)和Point.at(x,y)、Point.origin()。構造函數只能看出兩個參數,不知其意,後者更易理解。
性能
在某些情況下,可以事先進行實例化一些對象,調用時直接調用即可,不需要進行改變。比如,Boolean。
public final class Boolean implements Serializable, Comparable<Boolean> {
// 預先設置兩個對象
public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);
public Boolean(boolean var1) {
this.value = var1;
}
public Boolean(String var1) {
this(parseBoolean(var1));
}
// 工廠方法
public static Boolean valueOf(boolean var0) {
return var0?TRUE:FALSE; // 返回預先設置的對象,而不是創建對象
}
// 工廠方法
public static Boolean valueOf(String var0) {
return parseBoolean(var0)?TRUE:FALSE;
}
// ... other code
}
靈活性高
可根據具體情況,返回子類。相當於更強大的工廠。直接從父類獲取到子類。尤其適用於工具類(提供各種API)。例子:Collections。
public class Collections {
// 私有,典型工廠
private Collections() {
}
public static final List EMPTY_LIST = new EmptyList<>();
// 工廠方法
public static final <T> List<T> emptyList() {
return (List<T>) EMPTY_LIST;
}
private static class EmptyList<E> extends AbstractList<E> implements RandomAccess, Serializable {
// code
}
// 工廠方法
public static <E> List<E> checkedList(List<E> list, Class<E> type) {
// 根據具體情況,獲取相應子類
return (list instanceof RandomAccess ?
new CheckedRandomAccessList<>(list, type) :
new CheckedList<>(list, type));
}
// 子類1
static class CheckedRandomAccessList<E> extends CheckedList<E> implements RandomAccess {
CheckedRandomAccessList(List<E> list, Class<E> type) {
super(list, type);
}
public List<E> subList(int fromIndex, int toIndex) {
return new CheckedRandomAccessList<>(
list.subList(fromIndex, toIndex), type);
}
}
// 子類2
static class CheckedList<E> extends CheckedCollection<E> implements List<E> {
// code
}
}
2、多個構造函數時,考慮使用構造器
尤其在進行Android開發時,會碰到這種情況。通常是一個對象,具有多個成員變量可能需要初始化,常規方法,需要提供大量構造函數。例如:
// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
private AlertDialog(){}
public AlertDialog(int width, int height){ // 空白的警告框
AlertDialog(width,height,null);
}
// 帶標題的警告框
public AlertDialog(int width, int height, String title){ // 帶標題的警告框
AlertDialog(width, height, title, "確定");
}
// 帶標題的警告框,有確定按鈕
public AlertDialog(int width, int height, String title, String confirm){
AlertDialog(width, height, title, confirm, null);
}
// 帶標題的警告框,有確定按鈕,取消按鈕
public AlertDialog(int width, int height, String title, String confirm, String denyText){
// set every thing.
}
}
有多種樣式的警告框,爲了調用方便,必須提供多個構造函數。否則用戶在調用時,只能使用完整構造函數,容易犯錯且無法進行閱讀。極不靈活。如果採用另外一種方式,則可以解決,但會花費很多經歷處理併發的情況:
// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
public AlertDialog(){}// 空白的構造函數
public void setWidth(int width){
this.width = width;
}
// 其他set方法
}
調用時,通過調用各個參數的set方法進行設置。問題來了:
- 併發
- 無法進行參數校驗。
例如,只創建了對象,設置了標題,卻沒有尺寸,相當於創建了一個沒有尺寸的警告框。
在Android中,大量的控件都使用了構造器Builder。
// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
// private
private AlertDialog(){}
// Builder中使用
protected AlertDialog(Builder b){
width = b.width;
height = b.height;
// .....
if(width==0||height==0) throws new Exception("size must be set");
}
// 構造器
public static class Builder {
private int width;
private int height;
private String title;
private String confirmText;
private String denyText;
// 注意:返回的Builder。
public Builder setTitle(String title) {
this.title = title;
return this;
}
// 其他set...
public AlertDialog build(){
return AlertDialog(this);
}
}
}
於是,可以根據相應需求,進行相應設置,並在AlertDialog真正構造時,進行參數校驗。就像這樣:
new AlertDialog.Builder().setTitle("提示").build();
上述例子,會成功拋出異常。
3、用私有化構造器或者枚舉型強化Singleton。
Singleton指最多會被實例化一次的類。通常情況下,以前的做法是沒有問題的。但是在某些高級情況,通過使用反射的相關知識訪問private的構造函數,破壞Singleton。
public class Elvis{
// 注意,公有final對象
public static final Elvis INSTANCE = new Elvis();
private Elvis(){}
}
另一種情況,在序列化的過程中,反序列化得到的對象已經不再是以前的對象(破壞了Singleton),這種情況下,可以通過單元素枚舉型處理。
public enum Elvis{
INSTANCE;
// some methods
}
4、通過私有化構造器強化不可實例化的能力
有一些工具類,僅僅是提供一些能力,自己本身不具備任何屬性,所以,不適合提供構造函數。然而,缺失構造函數編譯器會自動添加上一個無參的構造器。所以,需要提供一個私有化的構造函數。爲了防止在類內部誤用,再加上一個保護措施和註釋。
public class Util{
private Util(){
// 拋出異常,防止內部誤調用
throw new AssertionError();
}
}
弊端是無法對該類進行繼承(子類會調用super())。
5、避免創建不必要的對象
- 對象的重用
- 昂貴的對象,使用對象池
- 廉價的對象,慎用對象池。
現代JVM對廉價對象的創建和銷燬非常快,此時不適於使用對象池。
6、消除過期的對象引用
以下三種情況可能會造成內存泄露:
- 自己管理的內存(數組長度減小後,pop出的對象容易導致內存泄漏)
緩存 - 監聽和回調
- 自己管理的內存
對於自己管理的內存要小心,比如:
public class Stack{
private Object[] elements;
private int size = 0;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
public Stack(){
elements = new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e){
ensureCapacity();
elements[size++]=e; // allocate新的堆內存和棧內存
}
public Object pop(){
if(size==0) throw new EmptyStackException();
return element[--size]; // pop出element[size],該對象不再有效。內存泄漏原因。
}
private void ensureCapacity(){
if(elements.length==size)
elements = Arrays.copyOf(elements, 2*size+1);
}
}
彈出的對象不再有效,但JVM不知道,所以會一直保持該對象,造成內存泄露。
解決:
public Object pop(){
if(size==0) throw new EmptyStackException();
elements[size] = null; // 等待回收
return element[--size];
}
緩存
緩存的對象容易被程序員遺忘,需要設置機制來維護緩存,例如不定期回收不再使用的緩存(使用定時器)。某些情況下,使用WeakHashMap可以達到緩存回收的功效。注,只有緩存依賴於外部環境,而不是依賴於值時,WeakHashMap纔有效。
監聽或回調
使用監聽和回調要記住取消註冊。確保回收的最好的實現是使用弱引用(weak reference),例如,只將他們保存成WeakHashMap的鍵。
7、避免顯示調用GC
Java的GC有強大的回收機制,可以簡單的記住:不要顯示調用finalizer。可以這樣理解:
jvm是針對具體的硬件設計的,然而程序卻不是針對具體硬件設計的,所以,java代碼無法很好的解決gc問題(因爲他具有平臺差異化)。另外,finalizer的性能開銷也非常大,從這個角度上考慮也不應該使用它。
8、覆蓋equals方法請遵守通用約定
- 自反性。x.equals(x) == true
- 對稱性。當前僅當y.equals(x)==true時,x.equals(y)==true
- 傳遞性。if(x.equals(y)&&y.equals(z)),y.equals(z)==true
一致性。 - 非空性。x.equals(null)==false
9、覆蓋equals方法時總要覆蓋hashCode
爲了保證基於散列的集合使用該類(HashMap、HashSet、HashTable),同時,也是Object.hashCode的通用約定,覆蓋equals方法時,必須覆蓋hashCode。
10、始終覆蓋toString
Object的toString方法的通用約定是該對象的描述。注意覆蓋時,如果有格式,請備註或者嚴格按照格式返回。
11、謹慎覆蓋clone
12、考慮實現Comparable接口
13、使類和成員的可訪問性最小化
目的是解耦。簡單來講,使用修飾符的優先級從大到小,private>protected>default(缺省)>public。如果在設計之初,設計爲private修飾符後,在之後的編碼過程如果不得不擴大其作用於,應該先檢查是否設計的確如此。
子類覆蓋超類,不允許訪問級別低於超類的訪問級別。(超類的protected,子類覆蓋後不能改爲default)。
成員變量決不允許是公有的。一旦設置爲公有,則放棄了對他處理的能力。這種類並不是線程安全的。即使是final的,也不允許。除非希望通過public static final來暴露常量。成員變量總是需要使用setter和getter來維護。有一個例外:長度非零的數組。這是安全漏洞的一個根源。
public Object pop(){
if(size==0) throw new EmptyStackException();
elements[size] = null; // 等待回收
return element[--size];
}
改進:
private static final Thing[] PRIVATE_VALUES = {...}
// 此時獲取到的纔是“常量”
public static final List<Thing> VALUS =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES))
另一種:
private static final Thing[] PRIVATE_VALUES = {...}
// 此時獲取到的纔是“常量”
public static final Thing[] values(){
return PRIVATE_VALUES.clone();
}
14、在公有類中使用訪問方法而非公有成員變量(類似13)
15、使可變性最小化
16、複合優先於繼承
繼承有利於代碼複用,但是儘可能不要進行跨包的繼承。包內的繼承是優秀的設計方式,一個包裏的文件處在同一個程序員的控制之下。但是繼承有其侷限性:子類依賴於超類。超類一旦發生更改,將可能破壞子類。並且,如果超類是有缺陷的,子類也會得“遺傳病”。
複合,即不擴展已有的類,而是在的類中新增一個現有類的。相當於現有類作爲一個組建存在於新類中。如此,將只會用到需要用到的東西,而不表現現有類所有的方法和成員變量。新類也可以稱爲“包裝類”,也就是設計模式中的Decorate模式。
17、要麼就爲繼承而設計,並提供文檔說明,要麼就禁止繼承
18、接口優於抽象類
19、接口只用於定義類型
20、類層次優先於標籤類
21、用函數對象表示策略
函數參數可以傳入類似listener的對象,目的是使用listener中的方法。如果使用匿名的參數,每一次調用會創建新的對象。可以將listener聲明爲成員變量,每次都複用同一個對象,並且可以使用靜態域(static變量)。比如String類的CASE_INSENSITIVE_ORDER域。
22、優先考慮靜態類成員
嵌套類的目的應該只是爲了他的外圍類提供服務,如果以後還可能用於其他環境中,則應該設計爲頂層類。靜態類相當於一個普通的外部類,只是恰好聲明在了一個類內部。通常的用戶是:Calculator.Operation.PLUS等。和普通類的區別只是,在PLUS前,有了2個前綴,來表明其含義。而非靜態類必須存在於外部類對象中。不要手動在外部創建一個內部非靜態類對象,創建的過程是:instance.New MemberClass()。這非常奇怪。
如果成員類不需要訪問外圍類,則需要添加static,是他成爲靜態成員類,否則每個實例都將包含一個額外指向外圍對象的引用。將會影響垃圾回收機制。
23、應指定泛型的具體類型,而不是直接使用原生類型。
例如,應該指定List,而不建議直接使用List。
24、消除非首檢警告
在使用IDE進行編碼時,強大的IDE都會在你編碼過程中提示warning,需要儘可能的消除warning,至少,應該小心這些warning。慎用SuppresWarning,如果IDE提示你可以通過添加該註解解決掉warning,請不要那麼做。如果實在要使用,請添加註釋說明原因。
25、列表優先於數組
類比泛型,數組是有一定缺陷的。List和List是沒有關係的,而Sub[]是Super[]的子類。
// Fails at runtime
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in"; // throw exception
// won't compile
List<Object> ol = new ArrayList<Long>(); // Incompatible types
ol.add("I don't fit in");
從代碼中可以看到,使用泛型,會提前發現錯誤。
26、優先考慮泛型
27、優先考慮泛型方法
28、利用有限制通配符來提升API的靈活性
PECS,producer-extends,consumer-super。
//public class Stack<E>{
// public Stack();
// public void push(E e);
// public E pop();
// public boolean isEmpty();
//}
public void pushAll(Iterator<? extends E> src){
for(E e : src)
push(e);
}
public void popAll(Collection<? super E> dst){
while(!isEmpty()){
dst.add(pop());
}
}
// Get and Put Principle
所有comparable和comparator都是消費者(Consumer)。
29、優先考慮類型安全的異構容器
30、用enum代替int常量
public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
public enum Orange { NAVEL, TEMPLE, BLOOD }
枚舉型在java中非常強大,當需要一組固定常量時,使用enum比int好很多。比如代碼可讀性,安全性等。
31、enum用實例域代替序數
// bad solution
public enum Ensemble {
SOLO, DUET, TRIO, QUARTET, QUINTET,
SEXTET, SEPTET, OCTET, NONET, DECTET;
public int numberOfMusicians() { return ordinal() + 1; }
}
//
// improvement
public enum Ensemble {
SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),
SEXTET(6), SEPTET(7), OCTET(8), NONET(9), DECTET(10), TRIPLE_QUARTET(12);
private final int numberOfMusicians;
Ensemble(int size) { this.numberOfMusicians = size; }
public int numberOfMusicians() { return numberOfMusicians; }
}
永遠不要像第一種的方式,利用序數訪問enum,需要在構造函數中使用參數來初始化。
32、用EnumSet代替位域
public class Text{
public static final int STYLE_BOLD = 1 << 0; // 1
public static final int STYLE_ITALIC = 1 << 1; // 2
public static final int STYLE_UNDERLINE = 1 << 2; // 4
public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8
public void applyStyles(int styles){
// ...
}
}
//
text.applyStyles(STYLE_BOLD | STYLE_ITALIC);
以上叫做位圖法,但是有更好的方案來傳遞多組常量——EnumSet。
public class Text{
public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }
// 注意此處,使用的是Set而不是EnumSet
public void applyStyles(Set<Style> styles){
// ...
}
}
//
text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));
33、用EnumMap代替序數索引
任何時候都不要使用enum的ordinal()方法。
34、用接口模擬可伸縮的枚舉
35、註解優先於命名模式
36、堅持使用Override註解
38、檢查參數的有效性
公有方法檢查參數,參數異常需要跑出Exception。私有方法利用斷言assertion檢查參數。
39、必要時進行保護性拷貝
假設類的客戶端會盡其所能來破壞這個類的約束條件,因此你必須保護性的設計程序。以下是一個不可變類的設計。
public Period(Date start, Date end){
this.start = new Date(start); // 使用了值的拷貝,沒有使用原對象(指針)
this.end = new Date(end);
if(this.start.compareTo(this.end)>0)
throw new IllegalArgumentException(start + " after " + end)
}
注意:保護性拷貝是在檢查參數之前進行的,防止多線程的影響。不要使用clone方法進行保護性拷貝。
以上方法防禦了傳入參數的修改,但是對於get方法獲取到的對象,仍然可以被修改,通過以下方法可以防止這種攻擊。
public Date start(){
return new Date(start);
}
public Date end(){
return new Date(end);
}
40、謹慎設計方法簽名
41、慎用重載
42、慎用可變參數
43、返回0長度的數組或者集合,而不是null
null一般用於表示沒有被初始化或處理,如果方法返回了null,則需要在上層做更多的處理,以防止NPE。
44、爲所有導出的API元素編寫文檔註釋
正確的javadoc文檔,需要每個被導出的類、接口、構造器、方法和域之前增加文檔註釋。註釋應該是對實現透明的,只需要簡潔的描述它和客戶端之間的約定。並且,還應該附上該方法的副作用。
45、將局部變量的作用域最小化
46、for-each優先於for循環
for-each規避掉了for循環的index變量的引用,通常來說它是不必要的——會增加引入錯誤的風險,並且風險一旦發生,很難被發現。不過有三種情況下,無法使用for-each(注:在jdk1.8中已經很好的解決了這些問題)。
- 過濾
- 轉換
- 平行迭代
47、如果需要精確的答案,請避免使用float和double
float和double是執行的二進制浮點運算,目的是在廣泛數值範圍上使用精確的快速近似計算而設計的。然而他們並沒有提供完全精確的計算(實際應用中,經常會碰到出現x.99999等結果)。尤其是,在進行貨幣計算時,他們並不適用。比如:
System.out.println(1.03-.42);
得到的結果將是:0.610000000001。
爲了解決這個問題,需要使用BigDecimal。然而這也有一些問題,相對於普通的運算,它顯得更加麻煩,而且也更慢。通常來說後一個缺點可以忽略,但是前者可能會讓人很不舒服。有一種做法是將需要處理的數值*10(或更多),使用int進行計算,不過需要你自己處理四捨五入等操作。
48、基本類型優先於裝箱基本類型
基本類型只有值,裝箱類具有與他們值不同的同一性。
基本類型只有功能完備的值,裝箱類還具有非功能值:
null。
所以你可能會碰到NPE
基本類型省空間省時間
50、如果有更精確的類型,請避免使用字符串
字符串不適合代替其他值的類型。
例如:int,boolean等
- 不適合代替枚舉類型(第30條)
- 不適合聚集類型
50、當心字符串連接的性能
操作符“+”可以將多個字符串進行連接。但是在大規模使用“+”的情況下,連接n個字符串的開銷是n的平房級時間。這是由於字符串的不可變性導致的。在這種情況下請使用StringBuilder進行連接。
51、通過接口引用對象
52、接口優先於反射機制
使用反射機制會帶來以下的問題:
- 喪失了編譯期類型檢查
- 代碼笨拙冗長
- 性能損失
反射基本上只適合用在編寫組件時、代碼分析器、RPC等場景下使用。在使用反射機制時,如果可能,儘可能只通過反射機制實例化對象,而訪問方法時,使用已知的接口或者超類。
53、謹慎使用JNI
54、謹慎進行優化
很多計算上的過失都被歸咎於效率(沒有必要達到的效率),而不是任何其他原因——甚至包括盲目的做傻事。
——William A. Wulf
不要去計較效率上的一些小小的得失,在97%的情況下,不成熟的優化纔是一切問題的根源。
——Donald E. Knuth
在優化方面,我們應該遵守兩條規則:
規則1:不要進行優化。
規則2(僅針對專家):還是不要進行優化——也就是說,在你還沒有絕對清晰的優化方案前,請不要進行優化。
——M. A. Jackson
這些格言比java的出現還要早20年。他們講述了一個關於優化的深刻事實:優化的弊大於利。
要努力編寫好的程序,而不是快的程序。低耦合的重要性遠遠大於性能。當程序編寫得足夠低耦合後,通過工具發現了性能瓶頸的代碼塊,纔可以保證對其的修改不影響任何外部環境。
55、遵守普遍的命名規則
56、只針對異常情況才使用異常
不要嘗試通過異常機制來做正常代碼應該做的事情,比如,檢查數組下標。
jvm很少對異常進行優化,因爲它只用於不正常的情況。並且,如果你將代碼放入try-catch代碼塊,jvm就喪失了本來可以對它進行的優化。
57、對於可恢復的情況使用受檢異常,對於編程錯誤的情況使用運行時異常
如果期望調用者適當的恢復,則需要使用受檢異常,強迫調用者食用try-catch代碼塊,或者將他們拋出去
當調用發生前提違例——違反約定的情況時,使用運行時異常,這個時候程序已經無法再執行下去了。
例如調用數組的-1索引。
作者:Dong GuoChao