大家好，這里是每周都陪你進步的網管～

其實也不是每周啦，上周陽了～實在是進步不動了...... 這周咱們繼續之前擱置了一段時間的設計模式系列。

上一次咱們分享的是職責鏈模式，在文章最后提到了一下裝飾器模式，兩者雖然結構上類似但在用途上還是有區別的，而裝飾器模式本身算是代理模式的一個特殊應用，所以這篇文章我們就先來學習一下代理模式的構成和用法，后面再來學習裝飾器。

老看我文章的同學可能發現了，雖然教材上是把設計模式分成了建造型、結構型、行為型三大塊展開的，但是我沒有按照這個大綱來鋪開內容，而是更注重延續性一點，力求盡量能做到由一種模式引出關聯的另外一種模式。所以在學完"流程開發的三個利器"—模版、策略和職責鏈三個行為型模式后，我們先把其他行為型的模式放一放，先來學習兩個結構型的模式—代理和裝飾器。

什么是代理模式

代理模式是一種結構型設計模式。 其中代理控制著對于原對象的訪問， 并允許在將請求提交給原對象的前后進行一些處理，從而增強原對象的邏輯處理。

上面的代理者我們一般叫做代理對象或者直接叫做代理-- Proxy，進行邏輯處理的原對象通常被稱作服務對象，代理要跟服務對象實現相同的接口，才能讓客戶端傻傻分不清自己使用的到底是代理還是真正的服務對象，這樣一來代理就能在客戶端察覺不到的情況下對服務對象的處理邏輯進行增強。

什么叫對處理邏輯進行增強？或者換一種說法，叫對核心功能添加增強功能？舉個例子來說，處理客戶端查詢用戶訂單信息的 API Handler 就是核心處理邏輯，增強邏輯就是我們需要在查詢訂單信息之前，驗證請求是否是有效用戶、記錄請求的參數和返回的響應數據等等。

看了上面代理模式的解釋，你可能還是覺得有點寬泛，下面咱們寫一個簡單的代碼示例，這個過程中你差不多就會發現：“誒，原來這就是代理模式啊，我之前寫代碼的時候早就用過了～！” 下面我們一起開下這個例子吧。

代理模式使用演示

假設有一個代表小汽車的 Car 類型

type Car struct{}

小汽車要的主要行為就是可以讓人駕駛，所以 Car 需要實現一個代表駕駛行為的接口（interface）Vehicle，該接口只有一個方法Drive()。

"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
type Vehicle interface {
    Drive()
}

type Car struct{}

func (c *Car) Drive() {
    fmt.Println("Car is being driven")
}

Car 的結構體指針通過實現Drive()?方法實現了Vehicle接口。

現在我們只要實例化一個Car?的實例，在實例上面調用Drive()方法就能讓車開起來，不過如果我們的駕駛員現在還是個未成年，那么在地球的大部分國家都是不允許開車的，如果在開車時要加一個駕駛員的年齡限制，我們該怎么辦呢？ 

給Car?結構體加一個Age?字段顯然是不合理的，因為我們要表示的駕駛員的年齡而不是車的車齡。同理駕駛員年齡的判斷我們也不應該加在 Car? 實現的 Drive()? 方法里， 這樣會導致每個實現 Vehicle ?接口的類型都要在自己的 Drive() 方法里加上類似的判斷。

這個時候通常的做法是，加一個表示駕駛員的類型 Driver。

type Driver struct {
    Age int
}

然后再來一個包裝 Driver 和 Vehicle 類型的包裝類型。

"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
type CarProxy struct {
    vehicle    Vehicle
    driver *Driver
}

func NewCarProxy(driver *Driver) *CarProxy {
    return &CarProxy{&Car{}, driver}
}

這樣的話我們接可以通過，用包裝類型代理vehicle?屬性的 Drive() 行為時，給它加上駕駛員的年齡限制。

func (c *CarProxy) Drive() {
    if c.driver.Age >= 16 {
        c.vehicle.Drive()
    } else {
        fmt.Println("Driver too young!")
    }
}

我相信這個編程技巧大家在平時開發中都用過，這個其實就是代理模式。

現在我們通過代理模式給 Car? 類型的 Drive() 行為擴充了檢查駕駛員的行為，下面我們執行一下程序試試效果。

"本文使用的完整可運行源碼
去公眾號「網管叨bi叨」發送【設計模式】即可領取"
func main() {
 car := NewCarProxy(&Driver{12})
 car.Drive() // 輸出 Driver too young!
 car2 := NewCarProxy(&Driver{22})
 car2.Drive() // 輸出 Car is being driven
}

正如執行后的結果所示，我們不必為服務對象 -- Car 類型添加任何屬性和方法。相反，我們只是在其上面的代理層把客戶端 Drive() 方法的調用委托（英文術語叫delegate）給了其 vehicle 屬性的 Drive 方法，并在之前添加了年齡檢查行為，從而達到我們想要的效果。

看完例子后，相信大家都理解了寫代碼時怎么使用代理模式，下面我們從代碼走出來，再更清晰的描述下代理模式它的整體結構。

看清代理模式

根據上面一開始的描述和后面的代碼例子，我們總結出來，參與代理模式的一共有四種角色：客戶端、服務接口、服務類和代理類，他們之間的關系用 UML 類圖表示如下：

代理模式--UML類圖

上面 UML 類圖一共有四個角色，這四個角色在代理模式中的職責分別是。

• 服務接口 （Ser-vice Inter-face） 聲明了服務類要實現的接口。 服務類的業務處理邏輯就是實現在這里定義的接口方法中，代理類也必須遵循該接口才能偽裝成服務對象。
• 服務 （Ser-vice） 類，就是上面說的，提供實際業務邏輯的原對象。
• 代理 （Proxy） 類包含一個服務對象作為成員變量。 代理完成其任務 （例如延遲初始化、記錄日志、 訪問控制和緩存等）后面會將請求傳遞給服務對象。通常情況下， 代理會對其服務對象的整個生命周期進行管理，來增強服務對象，這樣與核心業務邏輯不相關的增強邏輯就可以由代理來實現。
• 客戶端 （Client） 通過統一接口與服務或代理進行交互， 所以可在一切需要服務對象的代碼中使用服務對象的代理，客戶端完全不會感知到。

代理模式延伸

在代理模式中，通過讓代理類實現跟服務類相同的接口，從而把代理類偽裝成了服務類，客戶端請求代理時，代理再把請求委派給其持有的真實服務類，在委派的過程中我們就可以添加增強邏輯。

如果我們把代理類當成服務對象再給代理類加個代理，代理的代理再加代理，那么就變成了另外一種設計模式--裝飾器模式啦，其實裝飾器模式本身就是代理模式的一個特殊應用，關于裝飾器的內容，我們放到后面進行學習。