## 12.1. 爲何需要反射?

有時候我們需要編寫一個函數能夠處理一類併不滿足普通公共接口的類型的值，也可能是因爲它們併沒有確定的表示方式，或者是在我們設計該函數的時候還這些類型可能還不存在，各種情況都有可能。

一個大家熟悉的例子是fmt.Fprintf函數提供的字符串格式化處理邏輯，它可以用例對任意類型的值格式化併打印，甚至支持用戶自定義的類型。讓我們也來嚐試實現一個類似功能的函數。爲了簡單起見，我們的函數隻接收一個參數，然後返迴和fmt.Sprint類似的格式化後的字符串。我們實現的函數名也叫Sprint。

我們使用了switch類型分支首先來測試輸入參數是否實現了String方法，如果是的話就使用該方法。然後繼續增加類型測試分支，檢査是否是每個基於string、int、bool等基礎類型的動態類型，併在每種情況下執行相應的格式化操作。

```Go
func Sprint(x interface{}) string {
	type stringer interface {
		String() string
	}
	switch x := x.(type) {
	case stringer:
		return x.String()
	case string:
		return x
	case int:
		return strconv.Itoa(x)
	// ...similar cases for int16, uint32, and so on...
	case bool:
		if x {
			return "true"
		}
		return "false"
	default:
		// array, chan, func, map, pointer, slice, struct
		return "???"
	}
}
```

但是我們如何處理其它類似[]float64、map[string][]string等類型呢？我們當然可以添加更多的測試分支，但是這些組合類型的數目基本是無窮的。還有如何處理url.Values等命名的類型呢？雖然類型分支可以識别出底層的基礎類型是map[string][]string，但是它併不匹配url.Values類型，因爲它們是兩種不同的類型，而且switch類型分支也不可能包含每個類似url.Values的類型，這會導致對這些庫的循環依賴。

沒有一種方法來檢査未知類型的表示方式，我們被卡住了。這就是我們爲何需要反射的原因。