Effective Java - Check parameters for validity & Use varargs judiciously

Use varargs judiciously

varargs在我看這個item之前，我用的習以為常:

public String appendStrings(String ...strs) {
	StringBuilder sb = new StringBuilder();
	for( String str : strs ) {
		sb.append(str);
	}
	return sb.toString();
}

後來某天和同事討論到strs輸入檢查的問題時，就回來翻閱了這個item。假如你要限制client必須輸入一個或多個參數時，在method內做限制檢查並不是一個好的設計；書中建議做法可以如下:

public static String appendStrings(String first, String ...strs) {
	StringBuilder sb = new StringBuilder(first);
	for( String str : strs ) {
		sb.append(str);
	}
	return sb.toString();
}

透過限制必須傳入一個參數的方式，可以降低有人傳空資料的機會。除此之外，書中提到使用這種方式可能會導致效能問題，因為每次的呼叫JVM都會針對內容做array的allocation與initialization。從網路上別人做實驗的文章中發現，速度大概慢了60倍。

針對client的呼叫有95%的機會少於三個參數的人，書中給了以下workaround:

public void foo() { }
public void foo(int a1) { }
public void foo(int a1, int a2) { }
public void foo(int a1, int a2, int a3) { }
public void foo(int a1, int a2, int a3, int... rest) { }

還特別舉了JDK中的EnumSet，有使用到這個技術..

Reference:

1. Effective Java, 3/e, Item 53。

Check parameters for validity

這個item主要在探討檢查輸入參數是否合法。首先先看看不檢查的後果:

• Constructor: 錯誤的狀態會讓debug變得不容易。
• Method: (1)拋非預期的例外，通常是NullPointerException，最糟糕的是可以做完但結果不正確。例如傳入10筆要處理的資料但只回傳9筆結果；(2)錯誤的狀態。

而針對處理的建議，主要如下:

• Constructor或是Factory物件: 都應該要檢查，否則會增加debug成本。
• Method: 應該要檢查，但有幾種例外 1. 不切實際；2. 效能開銷很大； 3. 和後續工作有重疊。
• 針對拋出的例外，需加上註解說明。

method中的第二點與第三點的界定很清楚，我比較有疑問的是如何定義不切實際。這種參數檢查如果不如預期，我們通常會拋出IllegalArgumentException、IndexOutOfBoundsException或是NullPointerException；而這種例外屬於programming errors。如果實際狀況根本不可能發生，是否這就代表著不切實際呢? 畢竟如果做這樣子的檢查，我就會需要有對應的測試。因此，目前我的想法如下:

• 如果client code根本不會有這種使用方式，caller method不需要做檢查。
• 如果是要發佈出去或者是共用機會比較高的API，最好要做檢查。

另外書中有提到一個原則是: 如果參數足夠完成工作，限制應越少越好。這點也滿足Postel's Law所提倡的。

PS. 檢查可以考慮使用Guava的Preconditions，可以讓你的程式碼看起來較簡潔。

Reference:

1. Effective Java, 3/e, Item 49。