Go語言中的Interface

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

先給大家拜個早年：狗年WangWang旺

最近在看Go語言的物件導向的知識點時，發現它的物件導向能力全靠 interface 撐著，而且它的 interface 還與我們以前知道的 interface 完全不同。故而整個過程不斷的思考為什麼要如此設計？這樣設計給我們帶來了什麼影響？

interface 我不懂你

Rob Pike 曾說：

如果只能選擇一個Go語言的特 性移植到其他語言中，他會選擇介面

被Go語言設計者如此看重，想來 interface 一定是資質不凡，顏值爆表。但是說實話，當我第一次讀這部分內容的時候，我產生了以下三個問題：

1. 原來的 implement 方式產生了什麼問題，我用的不好好的嗎？
2. 如果不通過 implement 把介面與實作類別強制關聯起來，它怎麼知道我實現的哪個介面？
3. 這麼幹為實際編碼帶來了什麼影響或者說好處？

帶著這些問題我進行了一些比較與分析，Rob Pike 如此說，不可能是想騙我們都去用 Go，畢竟大家都是上過小學的，騙不了你們。

侵入式與非侵入式

在諸多的資料中，大家都提到 侵入式 與 非侵入式 這樣的概念，我用代碼來解釋下這兩個概念。

PHP 中的侵入式：

interface Person{    public function getAge();    public function getName();}class Student implements Person{    private $age;    private $name;    public function getAge()    {        return $this->age;    }        public function getName()    {        return $this->name;    }}

Go 中的非侵入式

type Person interface {    GetAge() int    GetName() string}type Student struct {    age int    name string}func (s Student) GetAge() int {    return s.age}func (s Student) GetName() string {    return s.name}func main() {    var p Person= Student{20, "Elon"}    fmt.Println("This person name is", p.GetName())    fmt.Println("This person age is", p.GetAge())}

通過上面的代碼我總結了以下問題：

1. 侵入式通過 implements 把實作類別與具體介面綁定起來了，因此有了強耦合;
2. 如果我修改了介面，比如改了介面方法，則實作類別必須改動；
3. 如果我希望實作類別再實現一個介面，實作類別也必須進行改動；
4. 後續跟進者，必須瞭解相關的介面。

這幾個問題是開發中經常遇到的問題，而 Go 非侵入式的方式完美解決了這幾個問題。他只要實現了與介面定義相同的方法，就算實現了某個介面，最重要的，隨著代碼的增加，你的類結構不會像 Java 那樣發生爆炸。因為你根本不用關心你實現了什麼介面，你只需要關心你的類有什麼方法，方法有什麼功能。在實作類別的時候也不需要像 Java、PHP 一樣引入各種介面，有可能你定義類的時候，某個介面還不存在，接下來我單獨說說該方式的意義。

interface 意義非凡

在我沒有理解之前，我覺得Go的介面很變扭，以前的碼代碼的思路都是：先設計好介面，再去做具體的實現。現在一個類你可能根本分不清他實現了那個介面。還是上面的例子，稍微改一下

type Person interface {    GetAge() int    GetName() string}type Car interface {    GetAge() int    GetName() string}type Student struct {    age int    name string}func (s Student) GetAge() int {    return s.age}func (s Student) GetName() string {    return s.name}

這裡有兩個介面 Person、Car 他們有相同的方法，而 Student 實現了這兩個方法，在 Go 裡邊就可以說他同時實現了這兩個介面，不信你試試

func main() {    var p Person= Student{20, "Elon"}    fmt.Println("This person name is", p.GetName())    fmt.Println("This person age is", p.GetAge())        var c Car= Student{1, "BMW"}    fmt.Println("This car name is", c.GetName())    fmt.Println("This car age is", c.GetAge())}

這裡只是為了說明問題，名字上看起來有點詭異(Student 竟然可以是車？上車就是上 Student？)

這種能力帶來的真正讓人吃驚的地方是什嗎？從此以後我可以先寫類了，我先根據實際情況把類的功能做好，在某個我具體需要使用的地方，我再定義介面。說的專業點：也就是介面是由使用方根據自己真實需求來定義，並且不用關心是否有其它使用方定義過。

這樣子到底解決了什麼開發中的問題？舉個例子：我們一個大團隊在開發一個商城系統，m端、app端、pc端都有購物車的需求，底層根據不同的需求已經實現了一個Cart類，通過該類可以擷取購物車價格、數量等。例如：

type Cart struct {    price float32    num int}func (c Cart) GetPrice() float32 {    return c.price}func (c Cart) GetNum() int {    return c.num}

這個時候前端要進行調用了，他們可以自由定義介面名稱用於接受，只需要關心自己的介面需要什麼方法，Cart 是否全部實現了需要的方法，每一個端完全可以自己定義一個介面，介面名稱、定義的方法順序都可以不同。

我覺得這才是真正做到了：依賴於介面而不是實現，優先使用組合而不是繼承

歡迎指正交流