適配器模式

將一個接口轉換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作。

image.png

package adapter


//適配器接口
type Target interface {
    Request() string
}

//被適配的目標接口
type Adaptee interface {
    SpecificRequest() string
}

//
type adapter struct {
    Adaptee
}

//Request 實現Target接口
func (a *adapter) Request() string {
    return a.SpecificRequest()
}

//NewAdapter 是Adapter的工廠函數
func NewAdapter(adaptee Adaptee) Target {
    return &adapter{
        Adaptee: adaptee,
    }
}

橋接模式

設想如果要繪制矩形、圓形、橢圓、正方形，我們至少需要4個形狀類，但是如果繪制的圖形需要具有不同的顏色，如紅色、綠色、藍色等。那么有兩種方案：1.為每一種形狀設置一套顏色方案；2.根據實際需要對形狀和顏色進行組合。第二種方案就是橋接模式，將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

image.png

優點

1.分離抽象接口及其實現部分。
2.橋接模式有時類似于多繼承方案，但是多繼承方案違背了類的單一職責原則

缺點

橋接模式的引入會增加系統的理解與設計難度，由于聚合關聯關系建立在抽象層，要求開發者針對抽象進

package bridge

import "fmt"

type Color interface {
    Use()
}

type Red struct{}

func (r Red) Use() {
    fmt.Println("Use Red color")
}

type Green struct{}

func (g Green) Use() {
    fmt.Println("Use Green color")
}

type Yellow struct{}

func (y Yellow) Use() {
    fmt.Println("Use Yellow color")
}

type BrushPen interface {
    DrawPicture()
}

type BigBrushPen struct {
    Color
}

func (bbp BigBrushPen) DrawPicture() {
    fmt.Println("Draw picture with big brush pen")
    bbp.Use()
}

裝飾器模式

動態地給一個對象增加一些額外的職責(Responsibility)，就增加對象功能來說，裝飾模式比生成子類實現更為靈活

image.png

package decorator

//原始接口
type Component interface {
    Calc() int
}
//原始類
type ConcreteComponent struct{}

func (*ConcreteComponent) Calc() int {
    return 0
}

//裝飾類
type MulDecorator struct {
    Component
    num int
}
//裝飾類實現了原始接口
func (d *MulDecorator) Calc() int {
    return d.Component.Calc() * d.num
}

func WarpMulDecorator(c Component, num int) Component {
    return &MulDecorator{
        Component: c,
        num:       num,
    }
}

外觀模式

外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

image.png

package facade

import "fmt"

type AModuleAPI interface {
    TestA() string
}

type BModuleAPI interface {
    TestB() string
}

//裝飾接口
type API interface {
    Test() string
}

//裝飾結構體
type apiImpl struct {
    a AModuleAPI
    b BModuleAPI
}

func (a *apiImpl) Test() string {
    aRet := a.a.TestA()
    bRet := a.b.TestB()
    return fmt.Sprintf("%s\n%s", aRet, bRet)
}

享元模式

運用共享技術有效地支持大量細粒度對象的復用。系統只使用少量的對象，而這些對象都很相似，狀態變化很小，可以實現對象的多次復用。

image.png

// 享元對象接口
type IFlyweight interface {
    Operation(int) //來自外部的狀態
}

// 共享對象
type ConcreteFlyweight struct {
    name string
}

func (c *ConcreteFlyweight) Operation(outState int) {
    if c == nil {
        return
    }
    fmt.Println("共享對象響應外部狀態", outState)
}

// 不共享對象
type UnsharedConcreteFlyweight struct {
    name string
}

func (c *UnsharedConcreteFlyweight) Operation(outState int) {
    if c == nil {
        return
    }
    fmt.Println("不共享對象響應外部狀態", outState)
}

代理模式

給某一個對象提供一個代 理，并由代理對象控制對原對象的引用

image.png

package proxy

type Subject interface {
    Do() string
}

type RealSubject struct{}

func (RealSubject) Do() string {
    return "real"
}

type Proxy struct {
    real RealSubject
}

func (p Proxy) Do() string {
    var res string

    // 在調用真實對象之前的工作，檢查緩存，判斷權限，實例化真實對象等。。
    res += "pre:"

    // 調用真實對象
    res += p.real.Do()

    // 調用之后的操作，如緩存結果，對結果進行處理等。。
    res += ":after"

    return res
}