大家好，這里是每周都在陪你進步的網管～！今天介紹一個在我們在開發做項目時，經常會用到的設計模式—適配器模式。
適配器模式（Adapter Pattern）又叫作變壓器模式，它的功能是將一個類的接口變成客戶端所期望的另一種接口，從而使原本因接口不匹配而導致無法在一起工作的兩個類能夠一起工作，屬于結構型設計模式。
適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以在一起工作。
我們用UML類圖看一下適配器模式的構成
適配器模式的結構
類圖-適配器模式的結構
適配器模式中的角色構成如下：
- 客戶端（Client）：首先是客戶端，這里的客戶端可以理解成通過適配器調用服務的代碼程序，代碼只需通過接口與適配器交互即可， 無需與具體的適配器類耦合。
- 客戶端接口（Client Interface）：這個接口也可被叫做適配器接口，描述了被適配的類與客戶端代碼協作時必須遵循的約定。
- 適配器 （Adapter）： 作為同時與客戶端和服務交互的中介類： 它在實現客戶端接口的同時封裝了服務對象。 適配器接受客戶端通過適配器接口發起的調用， 并將其轉換為適用于被封裝服務對象的調用。
- 服務（Service）：服務通常是一些第三方功能類庫或者是一些遺留系統的功能類，客戶端與其不兼容，因此無法直接調用其功能，需要適配器進行轉換。
通過上面的類圖里各個角色類的關聯我們可以看到，客戶端代碼只需通過接口與適配器交互即可， 無需與具體的適配器類耦合。 這樣， 如果有需求我們就可以向程序中添加新類型的適配器而無需修改已有適配器實現。 這在我們的項目需要替換服務類的時候很有用，符合SOLID原則里的開閉原則。
我們先來看看用代碼怎么實現適配器模式，稍后再給大家演示一個實踐性更高的例子。
//Target 適配器接口，描述客戶端和被適配服務間約定的接口
"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
type Target interface {
Request() string
}
//Adaptee 是被適配的目標接口
type Adaptee interface {
SpecificRequest() string
}
//NewAdaptee 是被適配接口的工廠函數
func NewAdaptee() Adaptee {
return &adapteeImpl{}
}
//AdapteeImpl 是被適配的目標類
type adapteeImpl struct{}
//SpecificRequest 是目標類的一個方法
func (*adapteeImpl) SpecificRequest() string {
return "adaptee method"
}
//NewAdapter 是Adapter的工廠函數
func NewAdapter(adaptee Adaptee) Target {
return &adapter{
Adaptee: adaptee,
}
}
//Adapter 是轉換Adaptee為Target接口的適配器
type adapter struct {
Adaptee
}
//Request 實現Target接口
func (a *adapter) Request() string {
return a.SpecificRequest()
}
客戶端代碼直接通過適配器來間接使用被適配對象的功能，解決了兩者不兼容的問題。
"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
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)
}
}
用適配器模式引入三方依賴
為什么建議引入依賴庫的時候使用適配器模式？項目使用第三方類庫的時候，防止未來有更換同等功能類庫的可能，一般會推薦使用適配器模式對三方類庫做一層封裝，這樣未來需要用同等功能的服務類進行替換時，實現一個新的適配器包裝服務類即可，不需要對已有的客戶端代碼進行更改。
使用適配器模式，在項目中接入依賴庫，這樣以后需要替換成其他同等功能的依賴庫的時候，不會影響到項目中的通過適配器使用依賴庫功能的代碼。
下面舉一個用適配器適配redigo庫為項目提供Redis Cache 功能的例子。
首先我們定義適配器接口，未來所有 Cache 類的適配器需要實現此接口。
import (
...
"github.com/gomodule/redigo/redis"
)
// Cache 定義適配器實現類要實現的接口
type Cache interface {
Put(key string, value interface{})
Get(key string) interface{}
GetAll(keys []string) map[string]interface{}
}
這里為了簡潔只定義了三個簡單的存取Cache的方法，實際使用時我們可以把常用的Cache操作都定義成接口的方法。
定義適配器實現類， RedisCache 類型會Cache接口，同時我們為RedisCache提供一個工廠方法，在工廠方法里進行 Redis 鏈接池的初始化
// RedisCache 實現適配器接口
"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
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實現 Cache 適配器接口的方法，這三個方法實現分別對應Redis的 SET、GET和MGET操作。
"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
// 緩存數據
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接口中定義的方法跟適配器交互，由適配器再去轉換成對三方依賴庫redigo的調用完成Redis操作。
func main() {
var rc Cache
rc = NewRedisCache()
rc.Put("網管叨逼叨", "rub fish")
}本文的完整源碼，已經同步收錄到我整理的電子教程里啦，可向我的公眾號「網管叨bi叨」發送關鍵字【設計模式】領取。
公眾號「網管叨bi叨」發送關鍵字【設計模式】領取。
適配器和代理模式的區別
適配器模式和代理模式同屬于結構型的設計模式，他們兩個在類結構上也非常相似，都是由一個包裝對象持有原對象，把客戶端對包裝對象的請求轉發到原對象上。那么這兩個模式有什么不同呢？我們怎么區分自己使用的是適配器還是代理模式？
適配器和代理模式的區別：
- 適配器與原對象（被適配對象）實現不同的接口，適配器的特點在于兼容，客戶端通過適配器的接口完成跟自己不兼容的原對象的訪問交互。
- 代理與原對象（被代理對象）實現相同的接口，代理模式的特點在于隔離和控制，代理直接轉發原對象的返回給客戶端，但是可以在調用原始對象接口的前后做一些額外的輔助工作，AOP編程的實現也是利用這個原理。
總結
適配器模式的優點是適配器類和原角色類解耦，提高程序的擴展性。在很多業務場景中符合開閉原則。不改變原有接口，卻還能使用新接口的功能。不過適配器的編寫過程需要結合業務場景全面考慮，同時也可能會增加系統的復雜性。
今天的文章就到這里啦，喜歡還請點個關注，每周更新最有實用性的編程知識。
