Go語言中的Interface

大愚Talk發表於2018-02-13
Go

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

最近在看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 是否全部實現了需要的方法，每一個端完全可以自己定義一個介面，介面名稱、定義的方法順序都可以不同。

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

歡迎指正交流

相關文章