什么是代理模式

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

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

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

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

代理模式使用演示

假設(shè)有一個代表小汽車的 Car 類型

type Car struct{}

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

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

Car 的結(jié)構(gòu)體指針通過實現(xiàn)Drive()方法實現(xiàn)了Vehicle接口。

現(xiàn)在我們只要實例化一個Car的實例，在實例上面調(diào)用Drive()方法就能讓車開起來，不過如果我們的駕駛員現(xiàn)在還是個未成年，那么在地球的大部分國家都是不允許開車的，如果在開車時要加一個駕駛員的年齡限制，我們該怎么辦呢？ 給Car結(jié)構(gòu)體加一個Age字段顯然是不合理的，因為我們要表示的駕駛員的年齡而不是車的車齡。同理駕駛員年齡的判斷我們也不應該加在 Car 實現(xiàn)的 Drive() 方法里， 這樣會導致每個實現(xiàn) Vehicle 接口的類型都要在自己的 Drive() 方法里加上類似的判斷。

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

type Driver struct {
    Age int
}

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

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!")
    }
}

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

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

func main() {
	car := NewCarProxy(&Driver{12})
	car.Drive() // 輸出 Driver too young!
	car2 := NewCarProxy(&Driver{22})
	car2.Drive() // 輸出 Car is being driven
}

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

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

看清代理模式

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

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

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

代理模式延伸

在代理模式中，通過讓代理類實現(xiàn)跟服務類相同的接口，從而把代理類偽裝成了服務類，客戶端請求代理時，代理再把請求委派給其持有的真實服務類，在委派的過程中我們就可以添加增強邏輯。 那么如果我們再給代理類加個代理，代理的代理再加代理，那么其實就變成了另外一種設(shè)計模式--裝飾器模式啦，其實裝飾器模式本身就是代理模式的一個特殊應用，關(guān)于裝飾器的內(nèi)容，我們放到后面進行學習。

以上就是深入理解Go設(shè)計模式之代理模式的詳細內(nèi)容，更多關(guān)于Go 代理模式的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論