摘要：本文主要聚焦在結構型模式（Structural Pattern）上，其主要思想是将多個對象組裝成較大的結構，并同時保持結構的靈活和高效，從程式的結構上解決子產品之間的耦合問題。
本文主要聚焦在結構型模式（Structural Pattern）上，其主要思想是将多個對象組裝成較大的結構，并同時保持結構的靈活和高效，從程式的結構上解決子產品之間的耦合問題。
組合模式（Composite Pattern）
簡述
在面向對象程式設計中，有兩個常見的對象設計方法，組合和繼承，兩者都可以解決代碼複用的問題，但是使用後者時容易出現繼承層次過深，對象關系過于複雜的副作用，進而導緻代碼的可維護性變差。是以，一個經典的面向對象設計原則是：組合優于繼承。
我們都知道，組合所表示的語義為“has-a”，也就是部分和整體的關系，最經典的組合模式描述如下：
将對象組合成樹形結構以表示“部分-整體”的層次結構，使得使用者對單個對象群組合對象的使用具有一緻性。
Go語言天然就支援了組合模式，而且從它不支援繼承關系的特點來看，Go也奉行了組合優于繼承的原則，鼓勵大家在進行程式設計時多采用組合的方法。Go實作組合模式的方式有兩種，分别是直接組合（Direct Composition）和嵌入組合（Embedding Composition），下面我們一起探讨這兩種不同的實作方法。
Go實作
直接組合（Direct Composition）的實作方式類似于Java/C++，就是将一個對象作為另一個對象的成員屬性。
一個典型的實作如《使用Go實作GoF的23種設計模式（一）》中所舉的例子，一個Message結構體，由Header和Body所組成。那麼Message就是一個整體，而Header和Body則為消息的組成部分。
type Message struct {
Header *Header
Body *Body
} 現在，我們來看一個稍微複雜一點的例子，同樣考慮上一篇文章中所描述的插件架構風格的消息處理系統。前面我們用抽象工廠模式解決了插件加載的問題，通常，每個插件都會有一個生命周期，常見的就是啟動狀态和停止狀态，現在我們使用組合模式來解決插件的啟動和停止問題。
首先給Plugin接口添加幾個生命周期相關的方法：
package plugin
...
// 插件運作狀态
type Status uint8
const (
Stopped Status = iota
Started
)
type Plugin interface {
// 啟動插件
Start()
// 停止插件
Stop()
// 傳回插件目前的運作狀态
Status() Status
}
// Input、Filter、Output三類插件接口的定義跟上一篇文章類似
// 這裡使用Message結構體替代了原來的string，使得語義更清晰
type Input interface {
Plugin
Receive() *msg.Message
}
type Filter interface {
Plugin
Process(msg *msg.Message) *msg.Message
}
type Output interface {
Plugin
Send(msg *msg.Message)
} 對于插件化的消息處理系統而言，一切皆是插件，是以我們将Pipeine也設計成一個插件，實作Plugin接口：
package pipeline
...
// 一個Pipeline由input、filter、output三個Plugin組成
type Pipeline struct {
status plugin.Status
input plugin.Input
filter plugin.Filter
output plugin.Output
}
func (p *Pipeline) Exec() {
msg := p.input.Receive()
msg = p.filter.Process(msg)
p.output.Send(msg)
}
// 啟動的順序 output -> filter -> input
func (p *Pipeline) Start() {
p.output.Start()
p.filter.Start()
p.input.Start()
p.status = plugin.Started
fmt.Println("Hello input plugin started.")
}
// 停止的順序 input -> filter -> output
func (p *Pipeline) Stop() {
p.input.Stop()
p.filter.Stop()
p.output.Stop()
p.status = plugin.Stopped
fmt.Println("Hello input plugin stopped.")
}
func (p *Pipeline) Status() plugin.Status {
return p.status
} 一個Pipeline由Input、Filter、Output三類插件組成，形成了“部分-整體”的關系，而且它們都實作了Plugin接口，這就是一個典型的組合模式的實作。Client無需顯式地啟動和停止Input、Filter和Output插件，在調用Pipeline對象的Start和Stop方法時，Pipeline就已經幫你按順序完成對應插件的啟動和停止。
相比于上一篇文章，在本文中實作Input、Filter、Output三類插件時，需要多實作3個生命周期的方法。還是以上一篇文章中的HelloInput、UpperFilter和ConsoleOutput作為例子，具體實作如下：
package plugin
...
type HelloInput struct {
status Status
}
func (h *HelloInput) Receive() *msg.Message {
// 如果插件未啟動，則傳回nil
if h.status != Started {
fmt.Println("Hello input plugin is not running, input nothing.")
return nil
}
return msg.Builder().
WithHeaderItem("content", "text").
WithBodyItem("Hello World").
Build()
}
func (h *HelloInput) Start() {
h.status = Started
fmt.Println("Hello input plugin started.")
}
func (h *HelloInput) Stop() {
h.status = Stopped
fmt.Println("Hello input plugin stopped.")
}
func (h *HelloInput) Status() Status {
return h.status
}
package plugin
...
type UpperFilter struct {
status Status
}
func (u *UpperFilter) Process(msg *msg.Message) *msg.Message {
if u.status != Started {
fmt.Println("Upper filter plugin is not running, filter nothing.")
return msg
}
for i, val := range msg.Body.Items {
msg.Body.Items[i] = strings.ToUpper(val)
}
return msg
}
func (u *UpperFilter) Start() {
u.status = Started
fmt.Println("Upper filter plugin started.")
}
func (u *UpperFilter) Stop() {
u.status = Stopped
fmt.Println("Upper filter plugin stopped.")
}
func (u *UpperFilter) Status() Status {
return u.status
}
package plugin
...
type ConsoleOutput struct {
status Status
}
func (c *ConsoleOutput) Send(msg *msg.Message) {
if c.status != Started {
fmt.Println("Console output is not running, output nothing.")
return
}
fmt.Printf("Output:\n\tHeader:%+v, Body:%+v\n", msg.Header.Items, msg.Body.Items)
}
func (c *ConsoleOutput) Start() {
c.status = Started
fmt.Println("Console output plugin started.")
}
func (c *ConsoleOutput) Stop() {
c.status = Stopped
fmt.Println("Console output plugin stopped.")
}
func (c *ConsoleOutput) Status() Status {
return c.status
} 測試代碼如下：
package test
...
func TestPipeline(t *testing.T) {
p := pipeline.Of(pipeline.DefaultConfig())
p.Start()
p.Exec()
p.Stop()
}
// 運作結果
=== RUN TestPipeline
Console output plugin started.
Upper filter plugin started.
Hello input plugin started.
Pipeline started.
Output:
Header:map[content:text], Body:[HELLO WORLD]
Hello input plugin stopped.
Upper filter plugin stopped.
Console output plugin stopped.
Hello input plugin stopped.
--- PASS: TestPipeline (0.00s)
PASS 組合模式的另一種實作，嵌入組合（Embedding Composition），其實就是利用了Go語言的匿名成員特性，本質上跟直接組合是一緻的。
還是以Message結構體為例，如果采用嵌入組合，則看起來像是這樣：
type Message struct {
Header
Body
}
// 使用時，Message可以引用Header和Body的成員屬性，例如：
msg := &Message{}
msg.SrcAddr = "192.168.0.1" 擴充卡模式（Adapter Pattern）
擴充卡模式是最常用的結構型模式之一，它讓原本因為接口不比對而無法一起工作的兩個對象能夠一起工作。在現實生活中，擴充卡模式也是處處可見，比如電源插頭轉換器，可以讓英式的插頭工作在中式的插座上。擴充卡模式所做的就是将一個接口Adaptee，通過擴充卡Adapter轉換成Client所期望的另一個接口Target來使用，實作原理也很簡單，就是Adapter通過實作Target接口，并在對應的方法中調用Adaptee的接口實作。
一個典型的應用場景是，系統中一個老的接口已經過時即将廢棄，但因為曆史包袱沒法立即将老接口全部替換為新接口，這時可以新增一個擴充卡，将老的接口适配成新的接口來使用。擴充卡模式很好的踐行了面向對象設計原則裡的開閉原則（open/closed principle），新增一個接口時也無需修改老接口，隻需多加一個适配層即可。
繼續考慮上一節的消息處理系統例子，目前為止，系統的輸入都源自于HelloInput，現在假設需要給系統新增從Kafka消息隊列中接收資料的功能，其中Kafka消費者的接口如下：
package kafka
...
type Records struct {
Items []string
}
type Consumer interface {
Poll() Records
} 由于目前Pipeline的設計是通過plugin.Input接口來進行資料接收，是以kafka.Consumer并不能直接內建到系統中。
怎麼辦？使用擴充卡模式！
為了能讓Pipeline能夠使用kafka.Consumer接口，我們需要定義一個擴充卡如下：
package plugin
...
type KafkaInput struct {
status Status
consumer kafka.Consumer
}
func (k *KafkaInput) Receive() *msg.Message {
records := k.consumer.Poll()
if k.status != Started {
fmt.Println("Kafka input plugin is not running, input nothing.")
return nil
}
return msg.Builder().
WithHeaderItem("content", "text").
WithBodyItems(records.Items).
Build()
}
// 在輸入插件映射關系中加入kafka，用于通過反射建立input對象
func init() {
inputNames["hello"] = reflect.TypeOf(HelloInput{})
inputNames["kafka"] = reflect.TypeOf(KafkaInput{})
}
... 因為Go語言并沒有構造函數，如果按照上一篇文章中的抽象工廠模式來建立KafkaInput，那麼得到的執行個體中的consumer成員因為沒有被初始化而會是nil。是以，需要給Plugin接口新增一個Init方法，用于定義插件的一些初始化操作，并在工廠傳回執行個體前調用。
package plugin
...
type Plugin interface {
Start()
Stop()
Status() Status
// 新增初始化方法，在插件工廠傳回執行個體前調用
Init()
}
// 修改後的插件工廠實作如下
func (i *InputFactory) Create(conf Config) Plugin {
t, _ := inputNames[conf.Name]
p := reflect.New(t).Interface().(Plugin)
// 傳回插件執行個體前調用Init函數，完成相關初始化方法
p.Init()
return p
}
// KakkaInput的Init函數實作
func (k *KafkaInput) Init() {
k.consumer = &kafka.MockConsumer{}
} 上述代碼中的kafka.MockConsumer為我們模式Kafka消費者的一個實作，代碼如下：
package kafka
...
type MockConsumer struct {}
func (m *MockConsumer) Poll() *Records {
records := &Records{}
records.Items = append(records.Items, "i am mock consumer.")
return records
} package test
...
func TestKafkaInputPipeline(t *testing.T) {
config := pipeline.Config{
Name: "pipeline2",
Input: plugin.Config{
PluginType: plugin.InputType,
Name: "kafka",
},
Filter: plugin.Config{
PluginType: plugin.FilterType,
Name: "upper",
},
Output: plugin.Config{
PluginType: plugin.OutputType,
Name: "console",
},
}
p := pipeline.Of(config)
p.Start()
p.Exec()
p.Stop()
}
// 運作結果
=== RUN TestKafkaInputPipeline
Console output plugin started.
Upper filter plugin started.
Kafka input plugin started.
Pipeline started.
Output:
Header:map[content:kafka], Body:[I AM MOCK CONSUMER.]
Kafka input plugin stopped.
Upper filter plugin stopped.
Console output plugin stopped.
Pipeline stopped.
--- PASS: TestKafkaInputPipeline (0.00s)
PASS 橋接模式（Bridge Pattern）
橋接模式主要用于将抽象部分和實作部分進行解耦，使得它們能夠各自往獨立的方向變化。它解決了在子產品有多種變化方向的情況下，用繼承所導緻的類爆炸問題。舉一個例子，一個産品有形狀和顔色兩個特征（變化方向），其中形狀分為方形和圓形，顔色分為紅色和藍色。如果采用繼承的設計方案，那麼就需要新增4個産品子類：方形紅色、圓形紅色、方形藍色、圓形紅色。如果形狀總共有m種變化，顔色有n種變化，那麼就需要新增m*n個産品子類！現在我們使用橋接模式進行優化，将形狀和顔色分别設計為一個抽象接口獨立出來，這樣需要新增2個形狀子類：方形和圓形，以及2個顔色子類：紅色和藍色。同樣，如果形狀總共有m種變化，顔色有n種變化，總共隻需要新增m+n個子類！
上述例子中，我們通過将形狀和顔色抽象為一個接口，使産品不再依賴于具體的形狀和顔色細節，進而達到了解耦的目的。橋接模式本質上就是面向接口程式設計，可以給系統帶來很好的靈活性和可擴充性。如果一個對象存在多個變化的方向，而且每個變化方向都需要擴充，那麼使用橋接模式進行設計那是再合适不過了。
回到消息處理系統的例子，一個Pipeline對象主要由Input、Filter、Output三類插件組成（3個特征），因為是插件化的系統，不可避免的就要求支援多種Input、Filter、Output的實作，并能夠靈活組合（有多個變化的方向）。顯然，Pipeline就非常适合使用橋接模式進行設計，實際上我們也這麼做了。我們将Input、Filter、Output分别設計成一個抽象的接口，它們按照各自的方向去擴充。Pipeline隻依賴的這3個抽象接口，并不感覺具體實作的細節。
package plugin
...
type Input interface {
Plugin
Receive() *msg.Message
}
type Filter interface {
Plugin
Process(msg *msg.Message) *msg.Message
}
type Output interface {
Plugin
Send(msg *msg.Message)
}
package pipeline
...
// 一個Pipeline由input、filter、output三個Plugin組成
type Pipeline struct {
status plugin.Status
input plugin.Input
filter plugin.Filter
output plugin.Output
}
// 通過抽象接口來使用，看不到底層的實作細節
func (p *Pipeline) Exec() {
msg := p.input.Receive()
msg = p.filter.Process(msg)
p.output.Send(msg)
} package test
...
func TestPipeline(t *testing.T) {
p := pipeline.Of(pipeline.DefaultConfig())
p.Start()
p.Exec()
p.Stop()
}
// 運作結果
=== RUN TestPipeline
Console output plugin started.
Upper filter plugin started.
Hello input plugin started.
Pipeline started.
Output:
Header:map[content:text], Body:[HELLO WORLD]
Hello input plugin stopped.
Upper filter plugin stopped.
Console output plugin stopped.
Pipeline stopped.
--- PASS: TestPipeline (0.00s)
PASS 總結
本文主要介紹了結構型模式中的組合模式、擴充卡模式和橋接模式。組合模式主要解決代碼複用的問題，相比于繼承關系，組合模式可以避免繼承層次過深導緻的代碼複雜問題，是以面向對象設計領域流傳着組合優于繼承的原則，而Go語言的設計也很好實踐了該原則；擴充卡模式可以看作是兩個不相容接口之間的橋梁，可以将一個接口轉換成Client所希望的另外一個接口，解決了子產品之間因為接口不相容而無法一起工作的問題；橋接模式将子產品的抽象部分和實作部分進行分離，讓它們能夠往各自的方向擴充，進而達到解耦的目的。