Go 設(shè)計(jì)模式｜項(xiàng)目依賴耦合度太高？可以用適配器做下優(yōu)化

作者：卡爾文_ 2023-02-06 08:54:59

適配器模式的優(yōu)點(diǎn)是適配器類(lèi)和原角色類(lèi)解耦，提高程序的擴(kuò)展性。在很多業(yè)務(wù)場(chǎng)景中符合開(kāi)閉原則。不改變?cè)薪涌冢瑓s還能使用新接口的功能。不過(guò)適配器的編寫(xiě)過(guò)程需要結(jié)合業(yè)務(wù)場(chǎng)景全面考慮，同時(shí)也可能會(huì)增加系統(tǒng)的復(fù)雜性。

大家好，這里是每周都在陪你進(jìn)步的網(wǎng)管～！今天介紹一個(gè)在我們?cè)陂_(kāi)發(fā)做項(xiàng)目時(shí)，經(jīng)常會(huì)用到的設(shè)計(jì)模式—適配器模式。

適配器模式（Adapter Pattern）又叫作變壓器模式，它的功能是將一個(gè)類(lèi)的接口變成客戶端所期望的另一種接口，從而使原本因接口不匹配而導(dǎo)致無(wú)法在一起工作的兩個(gè)類(lèi)能夠一起工作，屬于結(jié)構(gòu)型設(shè)計(jì)模式。

適配器模式使得原本由于接口不兼容而不能一起工作的那些類(lèi)可以在一起工作。

我們用UML類(lèi)圖看一下適配器模式的構(gòu)成

適配器模式的結(jié)構(gòu)

類(lèi)圖-適配器模式的結(jié)構(gòu)

適配器模式中的角色構(gòu)成如下：

客戶端（Client）：首先是客戶端，這里的客戶端可以理解成通過(guò)適配器調(diào)用服務(wù)的代碼程序，代碼只需通過(guò)接口與適配器交互即可，無(wú)需與具體的適配器類(lèi)耦合。
客戶端接口（Client Interface）：這個(gè)接口也可被叫做適配器接口，描述了被適配的類(lèi)與客戶端代碼協(xié)作時(shí)必須遵循的約定。
適配器（Adapter）：作為同時(shí)與客戶端和服務(wù)交互的中介類(lèi)：它在實(shí)現(xiàn)客戶端接口的同時(shí)封裝了服務(wù)對(duì)象。適配器接受客戶端通過(guò)適配器接口發(fā)起的調(diào)用，并將其轉(zhuǎn)換為適用于被封裝服務(wù)對(duì)象的調(diào)用。
服務(wù)（Service）：服務(wù)通常是一些第三方功能類(lèi)庫(kù)或者是一些遺留系統(tǒng)的功能類(lèi)，客戶端與其不兼容，因此無(wú)法直接調(diào)用其功能，需要適配器進(jìn)行轉(zhuǎn)換。

通過(guò)上面的類(lèi)圖里各個(gè)角色類(lèi)的關(guān)聯(lián)我們可以看到，客戶端代碼只需通過(guò)接口與適配器交互即可，無(wú)需與具體的適配器類(lèi)耦合。這樣，如果有需求我們就可以向程序中添加新類(lèi)型的適配器而無(wú)需修改已有適配器實(shí)現(xiàn)。這在我們的項(xiàng)目需要替換服務(wù)類(lèi)的時(shí)候很有用，符合SOLID原則里的開(kāi)閉原則。

我們先來(lái)看看用代碼怎么實(shí)現(xiàn)適配器模式，稍后再給大家演示一個(gè)實(shí)踐性更高的例子。

//Target 適配器接口，描述客戶端和被適配服務(wù)間約定的接口
"本文使用的完整可運(yùn)行源碼
去公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
type Target interface {
    Request() string
}

//Adaptee 是被適配的目標(biāo)接口
type Adaptee interface {
    SpecificRequest() string
}

//NewAdaptee 是被適配接口的工廠函數(shù)
func NewAdaptee() Adaptee {
    return &adapteeImpl{}
}

//AdapteeImpl 是被適配的目標(biāo)類(lèi)
type adapteeImpl struct{}

//SpecificRequest 是目標(biāo)類(lèi)的一個(gè)方法
func (*adapteeImpl) SpecificRequest() string {
    return "adaptee method"
}

//NewAdapter 是Adapter的工廠函數(shù)
func NewAdapter(adaptee Adaptee) Target {
    return &adapter{
        Adaptee: adaptee,
    }
}

//Adapter 是轉(zhuǎn)換Adaptee為T(mén)arget接口的適配器
type adapter struct {
    Adaptee
}

//Request 實(shí)現(xiàn)Target接口
func (a *adapter) Request() string {
    return a.SpecificRequest()
}

客戶端代碼直接通過(guò)適配器來(lái)間接使用被適配對(duì)象的功能，解決了兩者不兼容的問(wèn)題。

"本文使用的完整可運(yùn)行源碼
去公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
import "testing"

var expect = "adaptee method"

func TestAdapter(t *testing.T) {
    adaptee := NewAdaptee()
    target := NewAdapter(adaptee)
    res := target.Request()
    if res != expect {
        t.Fatalf("expect: %s, actual: %s", expect, res)
    }
}

用適配器模式引入三方依賴

為什么建議引入依賴庫(kù)的時(shí)候使用適配器模式？項(xiàng)目使用第三方類(lèi)庫(kù)的時(shí)候，防止未來(lái)有更換同等功能類(lèi)庫(kù)的可能，一般會(huì)推薦使用適配器模式對(duì)三方類(lèi)庫(kù)做一層封裝，這樣未來(lái)需要用同等功能的服務(wù)類(lèi)進(jìn)行替換時(shí)，實(shí)現(xiàn)一個(gè)新的適配器包裝服務(wù)類(lèi)即可，不需要對(duì)已有的客戶端代碼進(jìn)行更改。

使用適配器模式，在項(xiàng)目中接入依賴庫(kù)，這樣以后需要替換成其他同等功能的依賴庫(kù)的時(shí)候，不會(huì)影響到項(xiàng)目中的通過(guò)適配器使用依賴庫(kù)功能的代碼。

下面舉一個(gè)用適配器適配redigo庫(kù)為項(xiàng)目提供Redis Cache 功能的例子。

首先我們定義適配器接口，未來(lái)所有 Cache 類(lèi)的適配器需要實(shí)現(xiàn)此接口。

import (
  ...
 "github.com/gomodule/redigo/redis"
)
// Cache 定義適配器實(shí)現(xiàn)類(lèi)要實(shí)現(xiàn)的接口
type Cache interface {
 Put(key string, value interface{})
 Get(key string) interface{}
 GetAll(keys []string) map[string]interface{}
}

這里為了簡(jiǎn)潔只定義了三個(gè)簡(jiǎn)單的存取Cache的方法，實(shí)際使用時(shí)我們可以把常用的Cache操作都定義成接口的方法。

定義適配器實(shí)現(xiàn)類(lèi)， RedisCache 類(lèi)型會(huì)Cache接口，同時(shí)我們?yōu)镽edisCache提供一個(gè)工廠方法，在工廠方法里進(jìn)行 Redis 鏈接池的初始化

// RedisCache 實(shí)現(xiàn)適配器接口
"本文使用的完整可運(yùn)行源碼
去公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
type RedisCache struct {
 conn *redis.Pool
}

// RedisCache的工廠方法
func NewRedisCache() Cache {
 cache := &RedisCache{
  conn: &redis.Pool{
   MaxIdle:     7,
   MaxActive:   30,
   IdleTimeout: 60 * time.Second,
   Dial: func() (redis.Conn, error) {
    conn, err := redis.Dial("tcp", "localhost:6379")
    if err != nil {
     fmt.Println(err)
     return nil, err
    }

    if _, err := conn.Do("SELECT", 0); err != nil {
     conn.Close()
     fmt.Println(err)
     return nil, err
    }

    return conn, nil
   },
  },
 }
 return cache
}

接下來(lái)為RedisCache實(shí)現(xiàn) Cache 適配器接口的方法，這三個(gè)方法實(shí)現(xiàn)分別對(duì)應(yīng)Redis的 SET、GET和MGET操作。

"本文使用的完整可運(yùn)行源碼
去公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送【設(shè)計(jì)模式】即可領(lǐng)取"
// 緩存數(shù)據(jù)
func (rc *RedisCache) Put(key string, value interface{}) {
 if _, err := rc.conn.Get().Do("SET", key, value); err != nil {
  fmt.Println(err)
 }
}

// 獲取緩存中指定的Key的值
func (rc *RedisCache) Get(key string) interface{} {
 value, err := redis.String(rc.conn.Get().Do("GET", key))
 if err != nil {
  fmt.Println(err)
  return ""
 }
 return value
}

// 從緩存獲取多個(gè)Key的值
func (rc *RedisCache) GetAll(keys []string) map[string]interface{} {
 intKeys := make([]interface{}, len(keys))
 for i, _ := range keys {
  intKeys[i] = keys[i]
 }

 c := rc.conn.Get()
 entries := make(map[string]interface{})
 values, err := redis.Strings(c.Do("MGET", intKeys...))
 if err != nil {
  fmt.Println(err)
  return entries
 }

 for i, k := range keys {
  entries[k] = values[i]
 }

 return entries
}

客戶端在使用Cache時(shí)，是直接用Cache接口中定義的方法跟適配器交互，由適配器再去轉(zhuǎn)換成對(duì)三方依賴庫(kù)redigo的調(diào)用完成Redis操作。

func main() {
  var rc Cache
 rc = NewRedisCache()
 rc.Put("網(wǎng)管叨逼叨", "rub fish")
}

本文的完整源碼，已經(jīng)同步收錄到我整理的電子教程里啦，可向我的公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送關(guān)鍵字【設(shè)計(jì)模式】領(lǐng)取。

公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送關(guān)鍵字【設(shè)計(jì)模式】領(lǐng)取。

適配器和代理模式的區(qū)別

適配器模式和代理模式同屬于結(jié)構(gòu)型的設(shè)計(jì)模式，他們兩個(gè)在類(lèi)結(jié)構(gòu)上也非常相似，都是由一個(gè)包裝對(duì)象持有原對(duì)象，把客戶端對(duì)包裝對(duì)象的請(qǐng)求轉(zhuǎn)發(fā)到原對(duì)象上。那么這兩個(gè)模式有什么不同呢？我們?cè)趺磪^(qū)分自己使用的是適配器還是代理模式？

適配器和代理模式的區(qū)別：

適配器與原對(duì)象（被適配對(duì)象）實(shí)現(xiàn)不同的接口，適配器的特點(diǎn)在于兼容，客戶端通過(guò)適配器的接口完成跟自己不兼容的原對(duì)象的訪問(wèn)交互。
代理與原對(duì)象（被代理對(duì)象）實(shí)現(xiàn)相同的接口，代理模式的特點(diǎn)在于隔離和控制，代理直接轉(zhuǎn)發(fā)原對(duì)象的返回給客戶端，但是可以在調(diào)用原始對(duì)象接口的前后做一些額外的輔助工作，AOP編程的實(shí)現(xiàn)也是利用這個(gè)原理。