分析Go語言接口的設(shè)計原則

一、前言

go的interface寫起來更自由, 無需顯示的實現(xiàn), 只要實現(xiàn)了與interfece所包含的所有函數(shù)簽名的相同的方法即可。讓編碼更靈活, 易擴展。

如何理解go語言中的interface呢?

1. interface是方法聲明的集合

2.接口的方法與實現(xiàn)接口的類型方法格式一致

3.接口中所有方法均被實現(xiàn)

4. interface可以作為一種數(shù)據(jù)類型,實現(xiàn)了該接口的任何對象都可以給對應(yīng)的接口類型變量賦值

特別說明兩點：

• interface 可以被任意對象實現(xiàn)，一個類型/對象也可以實現(xiàn)多個 interface
• 方法不能重載，如eat(), eat(s string)不能同時存在

那么作為interface數(shù)據(jù)類型，他存在的意義在哪呢？ 實際上是為了滿足一些面向?qū)ο蟮木幊趟枷?。我們知道，軟件設(shè)計的最高目標就是高內(nèi)聚，低耦合。那么其中有一個設(shè)計原則叫開閉原則。什么是開閉原則

二、開閉原則

在面向?qū)ο缶幊填I(lǐng)域中，開閉原則規(guī)定“軟件中的對象（類，模塊，函數(shù)等等）應(yīng)該對于擴展是開放的，但是對于修改是封閉的”，這意味著一個實體是允許在不改變它的源代碼的前提下變更它的行為。

看重點: 對于擴展是開放的, 對于修改是封閉的.

舉個例子: 銀行每天要辦理不同的業(yè)務(wù), 存款, 轉(zhuǎn)賬, 取款等. 如果直接是實體來實現(xiàn)如下

package bank

import "fmt"

type Banker struct {

}

func (b *Banker) Save() {
    fmt.Println("存錢")
}

func (b *Banker) Transfer() {
    fmt.Println("轉(zhuǎn)賬")
}

func (b *Banker) Get() {
    fmt.Println("取錢")
}

有個人要來存錢取錢轉(zhuǎn)賬了

package main

import "aaa/bank"

func main() {
    var b = bank.Banker{}
    b.Save()
    b.Get()
    b.Transfer()
}

那么隨著業(yè)務(wù)越來越多, 越來越大. 我又要新增加一些業(yè)務(wù), 比如基金, 股票. 然后越來越多,越來越大. 導(dǎo)致Banker這個模塊越來越臃腫

這樣的設(shè)計會導(dǎo)致，當我們?nèi)ソoBanker添加新的業(yè)務(wù)的時候，會直接修改原有的Banker代碼，那么Banker模塊的功能會越來越多，出現(xiàn)問題的幾率也就越來越大，假如此時Banker已經(jīng)有99個業(yè)務(wù)了，現(xiàn)在我們要添加第100個業(yè)務(wù)，可能由于一次的不小心，導(dǎo)致之前99個業(yè)務(wù)也一起崩潰，因為所有的業(yè)務(wù)都在一個Banker類里，他們的耦合度太高，Banker的職責也不夠單一，代碼的維護成本隨著業(yè)務(wù)的復(fù)雜正比成倍增大。

我們使用開閉原則, 使用interface將banker模塊抽象出來. 然后根據(jù)這個抽象的模塊, 去實現(xiàn)save, get, transfer.....

那么依然可以搞定程序的需求。 然后，當我們想要給Banker添加額外功能的時候，之前我們是直接修改Banker的內(nèi)容，現(xiàn)在我們可以單獨定義一個股票Banker(實現(xiàn)股票方法)，到這個系統(tǒng)中。 而且股票Banker的實現(xiàn)成功或者失敗都不會影響之前的穩(wěn)定系統(tǒng)，他很單一，而且獨立。

所以以上，當我們給一個系統(tǒng)添加一個功能的時候，不是通過修改代碼，而是通過增添代碼來完成，那么就是開閉原則的核心思想了。所以要想滿足上面的要求，是一定需要interface來提供一層抽象的接口的。

golang代碼實現(xiàn)如下:

package bank

import "fmt"

// 對銀行的業(yè)務(wù)進行抽象
type Business interface {
    doBussiness()
}


// 存錢業(yè)務(wù)
type SaveBussiness struct {
}


func (b *SaveBussiness) doBussiness() {
    fmt.Sprintf("存錢")
}


//取錢業(yè)務(wù)
type GetBussiness struct {
}

func (g *GetBussiness) doBussiness() {
    fmt.Println("取錢")
}


// 轉(zhuǎn)賬業(yè)務(wù)
type TransferBusi struct {

}

func (t *TransferBusi) doBussiness() {
    fmt.Sprintf("轉(zhuǎn)賬")
}

然后我今天去了銀行, 我們封裝一個銀行, 銀行有各種各樣的能力.

package main

import (
    "aaa/bank"
    "fmt"
)

// 這有一個銀行, 銀行可以辦理業(yè)務(wù)
func Bank(b bank.Business) {
    fmt.Println("辦理業(yè)務(wù): ", b.DoBussiness())
}

func main() {
    // 辦理具體的業(yè)務(wù)
    Bank(bank.SaveBussiness{})
    Bank(bank.GetBussiness{})
    Bank(bank.TransferBusi{})
}

這樣, 當銀行增加業(yè)務(wù)類型, 比如股票的時候, 只需要擴展業(yè)務(wù)接口就可以了, 不會對原來的接口進行修改

再看開閉原則定義:開閉原則:一個軟件實體如類、模塊和函數(shù)應(yīng)該對擴展開放，對修改關(guān)閉。簡單的說就是在修改需求的時候，應(yīng)該盡量通過擴展來實現(xiàn)變化，而不是通過修改已有代碼來實現(xiàn)變化。

接口的意義:

現(xiàn)在interface已經(jīng)基本了解，那么接口的意義最終在哪里呢，想必現(xiàn)在你已經(jīng)有了一個初步的認知，實際上接口的最大的意義就是實現(xiàn)多態(tài)的思想，就是我們可以根據(jù)interface類型來設(shè)計API接口，那么這種API接口的適應(yīng)能力不僅能適應(yīng)當下所實現(xiàn)的全部模塊，也適應(yīng)未來實現(xiàn)的模塊來進行調(diào)用。 調(diào)用未來可能就是接口的最大意義所在吧，這也是為什么架構(gòu)師那么值錢，因為良好的架構(gòu)師是可以針對interface設(shè)計一套框架，在未來許多年卻依然適用。

三、依賴倒置原則

3.1、什么是依賴倒置原則　　

依賴倒置原則（Dependence Inversion Principle）是程序要依賴于抽象接口，不要依賴于具體實現(xiàn)。簡單的說就是要求對抽象進行編程，不要對實現(xiàn)進行編程，這樣就降低了客戶與實現(xiàn)模塊間的耦合。

3.2、一個耦合度極高的模塊關(guān)系設(shè)計

張三駕駛奔馳, 張三駕駛寶馬, 張三駕駛豐田.

李四駕駛寶馬, 李四駕駛奔馳, 李四駕駛豐田

package yldz

import "fmt"

// 奔馳車
type Benz struct {

}

func (b *Benz) run() string{
    return fmt.Sprintf("奔馳啟動")
}
// 寶馬
type BM struct {

}

func (b *BM) run() string{
    return fmt.Sprintf("寶馬啟動")
}
//豐田
type FT struct {

}

func (t *FT) run() string{
    return fmt.Sprintf("豐田啟動")
}
//====駕車人,張三
type Zhangsan struct {

}

func (t *Zhangsan) DriverBenz(b *Benz) {
    fmt.Println("張三駕駛", b.run())
}

func (t *Zhangsan) DriverBM(b *BM) {
    fmt.Println("張三駕駛", b.run())
}

func (t *Zhangsan) DriverFT(b *FT) {
    fmt.Println("張三駕駛", b.run())
}

// 駕車人----李四.......

package main

import "aaa/yldz"

func main() {
    z := yldz.Zhangsan{}
    z.DriverBenz(yldz.Benz{})
    z.DriverBM(yldz.BM{})
    z.DriverFT(yldz.FT{})
}

我們來看上面的代碼和圖中每個模塊之間的依賴關(guān)系，實際上并沒有用到任何的interface接口層的代碼，顯然最后我們的兩個業(yè)務(wù) 張三開奔馳, 李四開寶馬，程序中也都實現(xiàn)了。但是這種設(shè)計的問題就在于，小規(guī)模沒什么問題，但是一旦程序需要擴展，比如我現(xiàn)在要增加一個凱迪拉克汽車 或者 司機王五， 那么模塊和模塊的依賴關(guān)系將成指數(shù)級遞增，想蜘蛛網(wǎng)一樣越來越難維護和捋順。

3.3、面向抽象層依賴倒轉(zhuǎn)

如上圖所示，我們在設(shè)計一個系統(tǒng)的時候，將模塊分為3個層次，抽象層、實現(xiàn)層、業(yè)務(wù)邏輯層。

• 將抽象層的模塊和接口定義出來，這里就需要了interface接口的設(shè)計，
• 我們依照抽象層，依次實現(xiàn)每個實現(xiàn)層的模塊，在我們寫實現(xiàn)層代碼的時候，實際上我們只需要參考對應(yīng)的抽象層實現(xiàn)就好了，實現(xiàn)每個模塊，也和其他的實現(xiàn)的模塊沒有關(guān)系，這樣也符合了上面介紹的開閉原則。這樣實現(xiàn)起來每個模塊只依賴對象的接口，而和其他模塊沒關(guān)系，依賴關(guān)系單一。系統(tǒng)容易擴展和維護。
• 業(yè)務(wù)邏輯層也是一樣，只需要參考抽象層的接口來實現(xiàn)業(yè)務(wù)就好了，抽象層暴露出來的接口就是我們業(yè)務(wù)層可以使用的方法，然后可以通過多態(tài)的方向，接口指針指向哪個實現(xiàn)模塊，調(diào)用了就是具體的實現(xiàn)方法，這樣我們業(yè)務(wù)邏輯層也是依賴抽象成編程。

看看具體的實現(xiàn)

package yldz

import "fmt"

type Car interface {
    Run() string
}

type Driver interface {
    // 接口變量肚子里有一個指針, 所以接口變量不需要使用指針.
    Driver(car Car)
}


// 奔馳車
type Benz struct {

}

func (b *Benz) Run() string{
    return fmt.Sprintf("奔馳啟動")
}

// 寶馬車
type BM struct {

}

func (b *BM) Run() string{
    return fmt.Sprintf("寶馬啟動")
}

// 豐田車
type FT struct {

}

func (t *FT) Run() string{
    return fmt.Sprintf("豐田啟動")
}

// ====張三
type Zhangsan struct {

}

func (t *Zhangsan) Driver(car Car) {
    fmt.Println("駕駛",car.Run())
}

func main() {

    benz := yldz.Benz{}
    zs := yldz.Zhangsan{}
    zs.Driver(benz)

    ft := yldz.FT{}
    zs.Driver(ft)
}

以上就是分析Go語言接口的設(shè)計原則的詳細內(nèi)容，更多關(guān)于Go 接口的資料請關(guān)注腳本之家其它相關(guān)文章！