簡介

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

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

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

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

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

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

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

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

UML 結構

場景上下文

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

我們假設未來要上線一個不支持對接消息隊列的服務、結果數據也需要存儲到 ClickHouse 以供后續分析，為了應對未來多變的需求，我們有必要將監控系統設計得足夠的可擴展。

于是，整個模塊被設計為插件化風格的架構，Pipeline是數據處理的流水線，其中包含了Input、Filter和Output三類插件，Input負責從各類數據源中獲取監控數據，Filter負責數據處理，Output負責將處理后的數據輸出。

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

代碼實現

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

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

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

//關鍵點3：實現產品變化點的接口，這里是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)
}

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

//如果是結構體，直接把變化點作為成員變量來達到聚合的目的。
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實現，每次運行時新啟一個goroutine
typeSimplePipelinestruct{
pipelineTemplate
}

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

總結實現橋接模式的幾個關鍵點：

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

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

實現產品變化點的接口，這里是SocketInput,AddTimestampFilter和MemoryDbOutput。

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

擴展

TiDB 中的橋接模式

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

如上圖所示，每個Plugin都包含Validate、OnInit、OnShutdown、OnFlush四個待用戶實現的接口，它們可以按照各自的方向去變化，然后靈活組合在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 在實現插件框架時，使用函數式編程的方式來定義 OnXXX 接口，更具有 Go 風格。

典型應用場景

從多個維度上對系統/類/結構體進行擴展，如插件化架構。

在運行時切換不同的實現，如插件化架構。

用于構建與平臺無關的程序適配層。

優缺點

優點

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

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

缺點

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

與其他模式的關聯

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

文章配圖

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

審核編輯：劉清