實踐GoF的23種設(shè)計模式實現(xiàn)：橋接模式

簡介

GoF 對橋接模式（Bridge Pattern）的定義如下：

Decouple an abstraction from its implementation so that the two can vary independently.

也即，將抽象部分和實現(xiàn)部分進行解耦，使得它們能夠各自往獨立的方向變化。

橋接模式解決了在模塊有多種變化方向的情況下，用繼承所導致的類爆炸問題。

舉個例子，一個產(chǎn)品有形狀和顏色兩個特征（變化方向），其中形狀分為方形和圓形，顏色分為紅色和藍色。如果采用繼承的設(shè)計方案，那么就需要新增4個產(chǎn)品子類：方形紅色、圓形紅色、方形藍色、圓形紅色。如果形狀總共有 m 種變化，顏色有 n 種變化，那么就需要新增 m * n 個產(chǎn)品子類！

現(xiàn)在我們使用橋接模式進行優(yōu)化，將形狀和顏色分別設(shè)計為抽象接口獨立出來，這樣需要新增 2 個形狀子類：方形和圓形，以及 2 個顏色子類：紅色和藍色。同樣，如果形狀總共有 m 種變化，顏色有 n 種變化，總共只需要新增 m + n 個子類！

上述例子中，我們通過將形狀和顏色抽象為一個接口，使產(chǎn)品不再依賴于具體的形狀和顏色細節(jié)，從而達到了解耦的目的。橋接模式本質(zhì)上就是面向接口編程，可以給系統(tǒng)帶來很好的靈活性和可擴展性。如果一個對象存在多個變化的方向，而且每個變化方向都需要擴展，那么使用橋接模式進行設(shè)計那是再合適不過了。

當然，Go 語言從語言特性本身就把繼承剔除，但橋接模式中分離變化、面向接口編程的思想仍然值得學習。

UML 結(jié)構(gòu)

場景上下文

在簡單的分布式應(yīng)用系統(tǒng)（示例代碼工程）中，我們設(shè)計了一個 Monitor 監(jiān)控系統(tǒng)模塊，它可以看成是一個簡單的 ETL 系統(tǒng)，負責對監(jiān)控數(shù)據(jù)進行采集、處理、輸出。監(jiān)控數(shù)據(jù)來源于在線商場服務(wù)集群各個服務(wù)，當前通過消息隊列模塊 Mq 傳遞到監(jiān)控系統(tǒng)，經(jīng)處理后，存儲到數(shù)據(jù)庫模塊 Db 上。

我們假設(shè)未來要上線一個不支持對接消息隊列的服務(wù)、結(jié)果數(shù)據(jù)也需要存儲到 ClickHouse 以供后續(xù)分析，為了應(yīng)對未來多變的需求，我們有必要將監(jiān)控系統(tǒng)設(shè)計得足夠的可擴展。

于是，整個模塊被設(shè)計為插件化風格的架構(gòu)，Pipeline是數(shù)據(jù)處理的流水線，其中包含了Input、Filter和Output三類插件，Input負責從各類數(shù)據(jù)源中獲取監(jiān)控數(shù)據(jù)，F(xiàn)ilter負責數(shù)據(jù)處理，Output負責將處理后的數(shù)據(jù)輸出。

上述設(shè)計中，我們抽象出Input、Filter和Output三類插件，它們各種往獨立的方向變化，最后在Pipeline上進行靈活組合，這使用橋接模式正合適。

代碼實現(xiàn)

//關(guān)鍵點1：明確產(chǎn)品的變化點，這里是input、filter和output三類插件，它們各自變化

//demo/monitor/input/input_plugin.go
packageinput

//關(guān)鍵點2：將產(chǎn)品的變化點抽象成接口，這里是input.Plugin，filter.Plugin和output.Plugin
//Plugin輸入插件
typePlugininterface{
plugin.Plugin
Input()(*plugin.Event,error)
}

//關(guān)鍵點3：實現(xiàn)產(chǎn)品變化點的接口，這里是SocketInput,AddTimestampFilter和MemoryDbOutput
//demo/monitor/input/socket_input.go
typeSocketInputstruct{
socketnetwork.Socket
endpointnetwork.Endpoint
packetschan*network.Packet
isUninstalluint32
}

func(s*SocketInput)Input()(*plugin.Event,error){
packet,ok:=<-s.packets
????if?!ok?{
????????return?nil,?plugin.ErrPluginUninstalled
????}
????event?:=?plugin.NewEvent(packet.Payload())
????event.AddHeader("peer",?packet.Src().String())
????return?event,?nil
}

//?demo/monitor/filter/filter_plugin.go
package?filter

//?Plugin?過濾插件
type?Plugin?interface?{
????plugin.Plugin
????Filter(event?*plugin.Event)?*plugin.Event
}

//?demo/monitor/filter/add_timestamp_filter.go
//?AddTimestampFilter?為MonitorRecord增加時間戳
type?AddTimestampFilter?struct?{
}

func?(a?*AddTimestampFilter)?Filter(event?*plugin.Event)?*plugin.Event?{
????re,?ok?:=?event.Payload().(*model.MonitorRecord)
????if?!ok?{
????????return?event
????}
????re.Timestamp?=?time.Now().Unix()
????return?plugin.NewEvent(re)
}


//?demo/monitor/output/output_plugin.go
//?Plugin?輸出插件
type?Plugin?interface?{
????plugin.Plugin
????Output(event?*plugin.Event)?error
}

//?demo/monitor/output/memory_db_output.go
type?MemoryDbOutput?struct?{
????db????????db.Db
????tableName?string
}

func?(m?*MemoryDbOutput)?Output(event?*plugin.Event)?error?{
????r,?ok?:=?event.Payload().(*model.MonitorRecord)
????if?!ok?{
????return?fmt.Errorf("memory?db?output?unknown?event?type?%T",?event.Payload())
????}
????return?m.db.Insert(m.tableName,?r.Id,?r)
}

//?關(guān)鍵點4：定義產(chǎn)品的接口或者實現(xiàn)，通過組合的方式把變化點橋接起來。
//?demo/monitor/pipeline/pipeline_plugin.go
//?Plugin?pipeline由input、filter、output三種插件組成，定義了一個數(shù)據(jù)處理流程
//?數(shù)據(jù)流向為?input?->filter->output
//如果是接口，可以通過定義Setter方法達到聚合的目的。
typePlugininterface{
plugin.Plugin
SetInput(inputinput.Plugin)
SetFilter(filterfilter.Plugin)
SetOutput(outputoutput.Plugin)
}

//如果是結(jié)構(gòu)體，直接把變化點作為成員變量來達到聚合的目的。
typepipelineTemplatestruct{
inputinput.Plugin
filterfilter.Plugin
outputoutput.Plugin
isCloseuint32
runfunc()
}

func(p*pipelineTemplate)SetInput(inputinput.Plugin){
p.input=input
}

func(p*pipelineTemplate)SetFilter(filterfilter.Plugin){
p.filter=filter
}

func(p*pipelineTemplate)SetOutput(outputoutput.Plugin){
p.output=output
}

//demo/monitor/pipeline/simple_pipeline.go
//SimplePipeline簡單Pipeline實現(xiàn)，每次運行時新啟一個goroutine
typeSimplePipelinestruct{
pipelineTemplate
}

在本系統(tǒng)中，我們通過配置文件來靈活組合插件，利用反射來實現(xiàn)插件的實例化，實例化的實現(xiàn)使用了抽象工廠模式，詳細的實現(xiàn)方法可參考【Go實現(xiàn)】實踐GoF的23種設(shè)計模式：抽象工廠模式。

總結(jié)實現(xiàn)橋接模式的幾個關(guān)鍵點：

明確產(chǎn)品的變化點，這里是 input、filter 和 output 三類插件，它們各自變化。

將產(chǎn)品的變化點抽象成接口，這里是input.Plugin，filter.Plugin和output.Plugin。

實現(xiàn)產(chǎn)品變化點的接口，這里是SocketInput,AddTimestampFilter和MemoryDbOutput。

定義產(chǎn)品的接口或者實現(xiàn)，通過組合的方式把變化點橋接起來。這里是pipeline.Plugin通過Setter方法將input.Plugin，filter.Plugin和output.Plugin三個抽象接口橋接了起來。后面即可實現(xiàn)各類 input、filter 和 output 的靈活組合了。

擴展

TiDB 中的橋接模式

TiDB是一款出色的分布式關(guān)系型數(shù)據(jù)庫，它對外提供了一套插件框架，方便用戶進行功能擴展。TiDB 的插件框架的設(shè)計，也運用到了橋接模式的思想。

如上圖所示，每個Plugin都包含Validate、OnInit、OnShutdown、OnFlush四個待用戶實現(xiàn)的接口，它們可以按照各自的方向去變化，然后靈活組合在Plugin中。

//PluginpresentsaTiDBplugin.
typePluginstruct{
*Manifest
library*gplugin.Plugin
Pathstring
Disableduint32
StateState
}

//Manifestdescribesplugininfoandhowitcandobypluginitself.
typeManifeststruct{
Namestring
Descriptionstring
RequireVersionmap[string]uint16
Licensestring
BuildTimestring
//Validatedefinesthevalidatelogicforplugin.
//returnserrorwillstoploadpluginprocessandTiDBstartup.
Validatefunc(ctxcontext.Context,manifest*Manifest)error
//OnInitdefinestheplugininitlogic.
//itwillbecalledafterdomaininit.
//returnerrorwillstoploadpluginprocessandTiDBstartup.
OnInitfunc(ctxcontext.Context,manifest*Manifest)error
//OnShutDowndefinestheplugincleanuplogic.
//returnerrorwillwritelogandcontinueshutdown.
OnShutdownfunc(ctxcontext.Context,manifest*Manifest)error
//OnFlushdefinesflushlogicafterexecuted`flushtidbplugins`.
//itwillbecalledafterOnInit.
//returnerrorwillwritelogandcontinuewatchfollowingflush.
OnFlushfunc(ctxcontext.Context,manifest*Manifest)error
flushWatcher*flushWatcher

Versionuint16
KindKind
}

TiDB 在實現(xiàn)插件框架時，使用函數(shù)式編程的方式來定義 OnXXX 接口，更具有 Go 風格。

典型應(yīng)用場景

從多個維度上對系統(tǒng)/類/結(jié)構(gòu)體進行擴展，如插件化架構(gòu)。

在運行時切換不同的實現(xiàn)，如插件化架構(gòu)。

用于構(gòu)建與平臺無關(guān)的程序適配層。

優(yōu)缺點

優(yōu)點

可實現(xiàn)抽象不分與實現(xiàn)解耦，變化實現(xiàn)時，客戶端無須修改代碼，符合開閉原則。

每個分離的變化點都可以專注于自身的演進，符合單一職責原則。

缺點

過度的抽象（過度設(shè)計）會使得接口膨脹，導致系統(tǒng)復雜性變大，難以維護。

與其他模式的關(guān)聯(lián)

橋接模式通常與抽象工廠模式搭配使用，比如，在本文例子中，可以通過抽象工廠模式對各個 Plugin 完成實例化，詳情見【Go實現(xiàn)】實踐GoF的23種設(shè)計模式：抽象工廠模式。

文章配圖

可以在用Keynote畫出手繪風格的配圖中找到文章的繪圖方法。

審核編輯：劉清