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

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

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

(相關(guān)資料圖)

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

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

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

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

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

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

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

//Target 適配器接口，描述客戶端和被適配服務(wù)間約定的接口"本文使用的完整可運行源碼去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計模式】即可領(lǐng)取"type Target interface {    Request() string}//Adaptee 是被適配的目標接口type Adaptee interface {    SpecificRequest() string}//NewAdaptee 是被適配接口的工廠函數(shù)func NewAdaptee() Adaptee {    return &adapteeImpl{}}//AdapteeImpl 是被適配的目標類type adapteeImpl struct{}//SpecificRequest 是目標類的一個方法func (*adapteeImpl) SpecificRequest() string {    return "adaptee method"}//NewAdapter 是Adapter的工廠函數(shù)func NewAdapter(adaptee Adaptee) Target {    return &adapter{        Adaptee: adaptee,    }}//Adapter 是轉(zhuǎn)換Adaptee為Target接口的適配器type adapter struct {    Adaptee}//Request 實現(xiàn)Target接口func (a *adapter) Request() string {    return a.SpecificRequest()}

客戶端代碼直接通過適配器來間接使用被適配對象的功能，解決了兩者不兼容的問題。

"本文使用的完整可運行源碼去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計模式】即可領(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)    }}

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

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

使用適配器模式，在項目中接入依賴庫，這樣以后需要替換成其他同等功能的依賴庫的時候，不會影響到項目中的通過適配器使用依賴庫功能的代碼。

下面舉一個用適配器適配redigo庫為項目提供Redis Cache 功能的例子。

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

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

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

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

// RedisCache 實現(xiàn)適配器接口"本文使用的完整可運行源碼去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計模式】即可領(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}

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

"本文使用的完整可運行源碼去公眾號「網(wǎng)管叨bi叨」發(fā)送【設(shè)計模式】即可領(lǐng)取"http:// 緩存數(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}// 從緩存獲取多個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時，是直接用Cache接口中定義的方法跟適配器交互，由適配器再去轉(zhuǎn)換成對三方依賴庫redigo的調(diào)用完成Redis操作。

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

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

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

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

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

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

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

適配器模式的優(yōu)點是適配器類和原角色類解耦，提高程序的擴展性。在很多業(yè)務(wù)場景中符合開閉原則。不改變原有接口，卻還能使用新接口的功能。不過適配器的編寫過程需要結(jié)合業(yè)務(wù)場景全面考慮，同時也可能會增加系統(tǒng)的復(fù)雜性。

今天的文章就到這里啦，喜歡還請點個關(guān)注，每周更新最有實用性的編程知識。

關(guān)鍵詞： 適配器模式 設(shè)計模式 即可領(lǐng)取 一起工作