評: 爲什麼我不喜歡Go語言式的接口

最近在Go語言的QQ羣裏看到關於圖靈社區有牛人老趙吐槽許式偉《Go語言編程》的各種爭論.

我之前也看了老趙吐槽許式偉《Go語言編程》的文章, 當時想老趙如果能將許大書中不足部分補充完善了也是一個好事情. 因此, 對老趙的後續文章甚是期待.

誰知道看了老趙之後的兩篇吐槽Go語言的文章, 發現完全不是那回事情, 吐槽內容偏差太遠. 本來沒想摻和進來, 但是看到QQ羣裏和圖靈社區有很多人甚至把老趙的文章當作真理一樣. 實在忍不住, 昨天註冊了帳號, 進來也說下我的觀點.

這是老趙的幾篇文章:

• Go是一門有亮點的語言，老許是牛人，但這本書着實一般
• 爲什麼我認爲goroutine和channel是把別的平臺上類庫的功能內置在語言裏
• 爲什麼我不喜歡Go語言式的接口（即Structural Typing）

補充說明:

因爲當前這篇文章主要是針對老趙的不喜歡Go語言式的接口做 評論. 因爲標題的原因, 也造成了很大的爭議性(因爲很多人說我理解的很多觀點和老趙的原文不相符).

後面我會對Go語言的一些特性一些簡單的介紹, 但是不會是現在這種方式.

---

所謂Go語言式的接口，就是不用顯示聲明類型T實現了接口I，只要類型T的公開方法完全滿足接口I的要求，就可以把類型T的對象用在需要接口I的地方。這種做法的學名叫做Structural Typing，有人也把它看作是一種靜態的Duck Typing。除了Go的接口以外，類似的東西也有比如Scala裏的Traits等等。有人覺得這個特性很好，但我個人並不喜歡這種做法，所以在這裏談談它的缺點。當然這跟動態語言靜態語言的討論類似，不能簡單粗暴的下一個“好”或“不好”的結論。

原文觀點:

• Go的隱式接口其實就是靜態的Duck Typing. 很多語言(主要是動態語言)早就有.
• 靜態類型和動態類型沒有絕對的好和不好.

我的觀點:

• Go的隱式接口Duck Typing確實不是新技術, 但是在主流靜態編程語言中支持Duck Typing應該是很少的(不清楚目前是否只有Go語言支持).
• 靜態類型和動態類型雖然沒有絕對的好和不好, 但是每個都是有自己的優勢的, 沒有哪一個可以包辦一切. 而Go是試圖結合靜態類型和動態類型(interface)各自的優勢.

那麼就從頭談起：什麼是接口。其實通俗的講，接口就是一個協議，規定了一組成員，例如.NET裏的ICollection接口：

public interface ICollection {
   int Count { get; }
   object SyncRoot { get; }
   bool IsSynchronized { get; }
   void CopyTo(Array array, int index);
}

這就是一個協議的全部了嗎？事實並非如此，其實接口還規定了每個行爲的“特徵”。打個比方，這個接口的Count除了需要返回集合內元素的數目以外，還隱含了它需要在O(1)時間內返回這個要求。這樣一個使用了ICollection接口的方法才能放心地使用Count屬性來獲取集合大小，才能在知道這些特徵的情況下選用正確的算法來編寫程序，而不用擔心帶來性能問題，這才能實現所謂的“面向接口編程”。當然這種“特徵”並不但指“性能”上的，例如Count還包含了例如“不修改集合內容”這種看似十分自然的隱藏要求，這都是ICollection協議的一部分。

原文觀點:

• 接口就是一個協議, 規定了一組成員.
• 接口還規定了每個行爲對應時間複雜度的"特徵".
• 接口還規定了每個行爲還包含是否會修改集合的隱藏要求.

我的觀點:

• 第一條: 沒什麼可解釋的, 應該是接口的通俗含義.
• 第二條: 但是接口還包含時間複雜度的"特徵"就比較扯了. 請問這個特徵是由語言特性來約束(語言如何約束?), 還只是由接口的文檔作補充說明(這是語言的特性嗎)?
• 第三條: 這個還算是吐槽到了點子上. Go的接口確實不支持C++類似的const修飾, 除了接口外的method也不支持(Go的const關鍵字是另一個語義).

但是, C++中有了const就真的安全了嗎?

class Foo {
    private: mutable Mutex mutex_;

    public: void doSomething()const {
        MutexLocker locker(&mutex_);
        // const 已經被繞過了
    }
};

C++中方法const修飾唯一的用處就是增加各種編譯麻煩, 對使用者無法作出任何承諾. 使用者更關心的是doSomething的要做什麼, 上面的方法其實和void doSomethingConst()要表達的是類似的意思.

不管是靜態庫還是動態庫, 哪個能從庫一級保證某個函數是不能幹什麼的? 如果C++的const關鍵字並不能 真正的保證const, 而類似的實現細節(也包括前面提到的和時間複雜度相關的性能特徵)必須有文檔來補充. 那文檔應該以什麼形式提供(代碼註釋?Word文檔?其他格式文檔?)? 這些文檔真多能保證每個都會有人看嗎? 文檔說到底還只是人之間的口頭約定, 如果文檔真的那麼好使(還有實現), 那麼彙編語言也可以解決一切問題.

在Go語言是如何解決const和性能問題的?

首先, 對於C語言的函數參數傳值的語義, const是必然的結果. 但是, 如果參數太大要考慮性能的話, 就會考慮傳指針(還是傳值的語義), 通過傳指針就不能保證const的語義了. 如果連使用的庫函數都不能相信, 那怎麼就能相信它對於的頭文件所提供的const信息呢?

因爲, const和性能是相互矛盾的. Go語言中如果想絕對安全, 那就傳值. 如果想要性能(或者是返回副作用), 那就傳指針:

type Foo int

// 要性能
func (self *Foo)Get() int {
    return *self
}
// 要安全
func (self Foo)GetConst() int {
    return self
}

Go語言怎麼對待性能問題(還有單元測試問題)? 答案是集成go test測試工具. 在Go語言中測試代碼是pkg(包含package main)的一個組成部分. 不僅是普通的pkg可以go test, package main也可以用go test進行測試.

我們給前面的代碼加上單元測試和性能測試.

// foo_test.go

func TestGet(t *testing.T) {
    var foo Foo = 0
    if v := foo.Get(); v != 0 {
        t.Errorf("Bad Get. Need=%v, Got=%v", 0, v)
    }
}
func TestGetConst(t *testing.T) {
    var foo Foo = 0
    if v := foo.GetConst(); v != 0 {
        t.Errorf("Bad GetConst. Need=%v, Got=%v", 0, v)
    }
}

func BenchmarkGet(b *testing.B) {
    var foo Foo = 0
    for i := 0; i < b.N; i++ {
        _ = foo.Get()
    }
}
func BenchmarkGetConst(b *testing.B) {
    var foo Foo = 0
    for i := 0; i < b.N; i++ {
        _ = foo.GetConst()
    }
}

當然, 最終的測試結果還是給人來看的. 如果實現者/使用者故意搞破壞, 再好的工具也是沒辦法的.

由此我們還可以解釋另外一些問題，例如爲什麼.NET裏的List不叫做ArrayList，當然這些都只是我的推測。我的想法是，由於List與IList接口是配套出現的，而像IList的某些方法，例如索引器要求能夠快速獲取元素，這樣使用IList接口的方法才能放心地使用下標進行訪問，而滿足這種特徵的數據結構就基本與數組難以割捨了，於是名字裏的Array就顯得有些多餘。

假如List改名爲ArrayList，那麼似乎就暗示着IList可以有其他實現，難道是LinkedList嗎？事實上，LinkedList根本與IList沒有任何關係，因爲它的特徵和List相差太多，它有的盡是些AddFirst、InsertBefore方法等等。當然，LinkedList與List都是ICollection，所以我們可以放心地使用其中一小部分成員，它們的行爲特徵是明確的。

原文觀點:

• 推測: 因爲爲了和IList<T>接口配套出現的原因, 纔沒有將List<T>命名爲ArrayList<T>.
• 因爲IList<T>(這個應該是筆誤, 我覺得作者是說List<T>)索引器要求能夠快速獲取元素, 這樣使用IList接口的方法才能放心地使用下標進行訪問(實現的算法複雜度特徵向接口方向傳遞了).
• 不能將List<T>改爲ArrayList<T>的另一個原因是LinkedList<T>. 因爲List<T>和LinkedList<T>的時間複雜度不一樣, 所以不能是一個接口(大概是一個算法複雜度一個接口的意思?).
• LinkedList<T>與List<T>都屬於ICollection<T>這個祖宗接口.

我的觀點:

• 第一條: 我不知道原作者是怎麼推測的. 接口的本意就是要和實現分離. 現在卻完全綁定到一起了, 那這樣還要接口做什麼(一個Xxx<T>對應一個IXxx<T>接口)?
• 第二條: 因爲運行時向接口傳遞了某個時間複雜度的實現, 就推導出接口的都符合某種時間複雜度, 邏輯上根本就不通!
• 第三條: 和前兩個差不多的意思, 沒什麼可說的.
• 第四條: 這個應該是Go非入侵接口的優點. C++/Java就是因爲接口的入侵性, 才導致了接口和實現無法完全分離. 因爲, C++/Java大部分時間都在整理接口間/實現間的祖宗八代之間的關係了(重要的不是如何分類, 而是能做什麼). 可以參考許式偉給的Java的例子(瞭解祖宗八代之間的關係真的很重要嗎): http://docs.oracle.com/javase/1.4.2/docs/api/overview-tree.html.

這方面的反面案例之一便是Java了。在Java類庫中，ArrayList和LinkedList都實現了List接口，它們都有get方法，傳入一個下標，返回那個位置的元素，但是這兩種實現中前者耗時O(1)後者耗時O(N)，兩者大相近庭。那麼好，我現在要實現一個方法，它要求從第一個元素開始，返回每隔P個位置的元素，我們還能面向List接口編程麼？假如我們依賴下標訪問，則外部一不小心傳入LinkedList的時候，算法的時間複雜度就從期望的O(N/P)變成了O(N2/P)。假如我們選擇遍歷整個列表，則即便是ArrayList我們也只能得到O(N)的效率。話說回來，Java類庫的List接口就是個笑話，連Stack類都實現了List，真不知道當年的設計者是怎麼想的。

簡單地說，假如接口不能保證行爲特徵，則“面向接口編程”沒有意義。

原文觀點:

• Java的ArrayList和LinkedList都實現了List接口, 但是get方法的時間複雜度不同.
• 假如接口不能保證行爲特徵，則“面向接口編程”沒有意義。

我的觀點:

• 第一條: 這其實是原作者列的一個前提, 是爲了推出第二條的結論. 但是, 我覺得這裏的邏輯同樣是有問題的. 有這個例子只能說明接口有它的不足, 但是怎麼就證明了 則“面向接口編程”沒有意義?
• 第二條: 我要反問一句, 爲什麼非要在這裏使用接口(難道是被C++/Java的面向對象洗腦了)? 接口有它合適的地方(面向邏輯層面), 也有它不合適的地方(面向底層算法層面). 在這裏爲什麼不直接使用ArrayList或LinkedList?

而Go語言式的接口也有類似的問題，因爲Structural Typing都只是從表面（成員名，參數數量和類型等等）去理解一個接口，並不關注接口的規則和含義，也沒法檢查。忘了是Coursera裏哪個課程中提到這麼一個例子：

nterface IPainter {
    void Draw();
}

nterface ICowBoy {
     void Draw();
}

在英語中Draw同時具有“畫畫”和“拔槍”的含義，因此對於畫家（Painter）和牛仔（Cow Boy）都可以有Draw這個行爲，但是兩者的含義截然不同。假如我們實現了一個“小明”類型，他明明只是一個畫家，但是我們卻讓他去跟其他牛仔決鬥，這樣就等於讓他去送死嘛。另一方面，“小王”也可以既是一個“畫家”也是個“牛仔”，他兩種Draw都會，在C#裏面我們就可以把他實現爲：

class XiaoWang : IPainter, ICowBoy {
    void IPainter.Draw() {
         // 畫畫
    }

    void ICowBoy.Draw() {
         // 掏槍
    }
}

因此我也一直不理解Java的取捨標準。你說這樣一門強調面向對象強調接口強調設計的語言，還要求強制異常，怎麼就不支持接口的顯示實現呢？

原文觀點:

• 不同實現的Draw含義不同, 因此接口最好也能支持不同的實現.
• Java/Go之類的接口都沒有C#的接口強大.

我的觀點:

• 第一條: 不要因爲自己有個錘子, 就把什麼東西都當作釘子! 你這個是C#的例子(我不懂C#), 但是請不要往Go語言上套! 之前是C++搞出了個函數重載(語義還是相似的, 但是簽名不同), 沒想到C#還搞了個支持同一個單詞不同含義的特性.
• 第二條: 只能說原作者真的不懂Go語言.

Go語言爲什麼不支持這些花哨的特性? 因爲, 它們太複雜且沒多大用處, 寫出的代碼不好理解(如果原作者不提示, 誰能發現Darw的不同含義這個坑?). Go語言的哲學是: "Less is more!".

看看Go語言該怎麼做:

type Painter interface {
    Draw()
}
type CowBoyer interface {
    DrawTheGun()
}

type XiaoWang struct {
    // ...
}

func (self *XiaoWang)Draw() {
    // ...
}
func (self *XiaoWang)DrawTheGun() {
    // ...
}

XiaoWang需要關心的只是自己有哪些功能(method), 至於祖宗關係開始根本不用關心. 等到XiaoWang各種特性逐漸成熟穩定之後, 發現新來的XiaoMing也有類似的功能特徵, 這個時候纔會考慮如何用接口來描述XiaoWang和XiaoMing共同特徵.

這就是我更傾向於Java和C#中顯式標註異常的原因。因爲程序是人寫的，完全不會因爲一個類只是因爲存在某些成員，就會被當做某些接口去使用，一切都是經過“設計”而不是自然發生的。就好像我們在泰國不會因爲一個人看上去是美女就把它當做女人，這年頭的化妝和PS技術太可怕了。

原文觀點:

• 接口是經過“設計”而不是自然發生的.
• 接口有不足, 因爲在泰國不能根據美女這個接口來推斷這個人是女人這個類型.

我的觀點:

• Go的哲學是先構造具體對象, 然後再根據共性慢慢歸納出接口, 一開始不用關心祖宗八代的關係.
• 請問女人是怎麼定義的, 難道這不是一個接口?

我這裏再小人之心一把：我估計有人看到這裏會說我只是酸葡萄心理，因爲C#中沒有這特性所以說它不好。還真不是這樣，早在當年我還沒聽說Structural Typing這學名的時候就考慮過這個問題。我寫了一個輔助方法，它可以將任意類型轉化爲某種接口，例如：

XiaoMing xm = new XiaoMing();
ICowBoy cb = StructuralTyping.From(xm).To<ICowBoy>();

於是，我們就很快樂地將只懂畫畫的小明送去決鬥了。其內部實現原理很簡單，只是使用Emit在運行時動態生成一個封裝類而已。此外，我還在編譯後使用Mono.Cecil分析程序集，檢查From與To的泛型參數是否匹配，這樣也等於提供了編譯期的靜態檢查。此外，我還支持了協變逆變，還可以讓不需要返回值的接口方法兼容存在返回值的方法，這可比簡單通過名稱和參數類型判斷要強大多了。

原文觀點:

• C#接口的這個特性很NB...

我的觀點:

我們看看Go是該怎麼寫(基於前面的Go代碼, 沒有Draw重載):

var xm interface{} = new(XiaoWang)
cb := xm.(Painter).(CowBoyer)

但是, 我覺得這樣寫真的很變態. Go語言是爲了解決實際的工程問題的, 不是要像C++那樣成爲各種NB技術的大雜燴.

我始終認同一個觀點: 任何語言都可以寫出垃圾代碼, 但是不能以這些垃圾代碼來證明原語言也垃圾.

有了多種選擇，我才放心地說我喜歡哪個。JavaScript中只能用回調編寫代碼，於是很多人說它是JavaScript的優點，說回調多麼多麼美妙我會深不以爲然——只是沒法反抗開始享受罷了嘛……

這篇文章好像吐槽有點多？不過這小文章還挺爽的。

這段不是接口相關, 懶得整理/吐槽了.

---

最後我只想說一個例子, 從C語言時代就很流行的printf函數. 我們看看Go語言中是什麼樣子(fmt.Fprintf):

func Fprintf(w io.Writer, format string, a ...interface{}) (n int, err error)

在Go語言中, fmt.Fprintf只關心怎麼識別各種a ...interface{}, 怎麼format這些參數, 至於怎麼寫, 寫到哪裏去那完全是w io.Writer的事情.

這裏第一個參數的w io.Writer就是一個接口, 它不僅可以寫到File, 也可以寫到net.Conn, 準確的說是可以寫到任何實現了io.Writer接口的對象中.

因爲, Go語言接口的非入侵性, 我們可以獨立實現自己的對象, 只要符合io.Writer接口就行, 然後就可以和fmt.Fprintf配合工作.

後面的可變參數interface{}同樣是一個接口, 它代替了C語言的void*, 用於格式化輸出各種類型的值. (更準確的講, 除了基礎類型, 參數a必須是一個實現了Stringer接口的擴展類型).

接口是一個完全正交的特性, 可以將Fprintf從各種a ...interface{}, 以及各種w io.Writer完全剝離出來. Go語言也是這樣, struct等基礎類型的內存佈局還是和C語言中一樣, 只是加了個method(在Go1.1中, method value就是一個普通閉包函數), 接口以及goroutine都是在沒有破壞原有的類型語義基礎上正交擴展(而不是像C++那樣搞個構造函數, 以後又是析構函數的).

我到很想知道, 在C++/C#/Java之類的語言中, 是如何實現fmt.Fprintf的.

---

套用原作者的一句話作爲結束: Go語言雖然有缺點, 即使老趙是牛人, 但是這篇吐槽也着實一般!