裝飾器模式
什么是裝飾器模式太惠？
裝飾器模式（Decorator Pattern）允許向一個(gè)現(xiàn)有的對(duì)象添加新的功能，同時(shí)又不改變其結(jié)構(gòu)只嚣。這種類型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式腻贰，它是作為現(xiàn)有的類的一個(gè)包裝。
上面說的可能有點(diǎn)抽象巩搏，簡單來說昨登，就是在原來的功能上進(jìn)行擴(kuò)展，給它新增一個(gè)或多個(gè)功能贯底。有人可能會(huì)覺得丰辣，加功能就是往原來的邏輯上加代碼。要注意的是這里說的是對(duì)功能進(jìn)行擴(kuò)展禽捆，而不是修改笙什，就是保證原來的功能是不變的。
舉例1
需求來了
我有一個(gè)接口胚想，功能就是讀取用戶信息的琐凭，這是它的核心功能，核心函數(shù)就是讀取數(shù)據(jù)庫的函數(shù)浊服。
現(xiàn)在因?yàn)榻涌谡?qǐng)求很頻繁统屈，我要給它加一個(gè)緩存功能胚吁，以減輕數(shù)據(jù)庫的請(qǐng)求壓力。
- 讀取用戶信息
// 用戶
type User struct{
}
func New() *User
// 查詢用戶信息
func (u *User) Read() {
}
func main() {
// 創(chuàng)建
u := New()
// 讀取用戶信息
u.Read()
}
- 現(xiàn)在為用戶信息添加緩存
直接在上面加代碼愁憔，上來就擼袖子加代碼腕扶，不考慮設(shè)計(jì)模式
// 獲取用戶緩存
func GetUserCache(uid int) *User{
// ...
}
// 設(shè)置用戶緩存
func SetUserCache(u *User) {
}
func main() {
uid := 123
// 用戶信息有緩存
if u := GetUserCache(uid);u != nil {
return
}
// 創(chuàng)建
u := New()
// 讀取用戶信息
u.Read()
// 設(shè)置用戶緩存
SetUserCache(u)
}
- 通過裝飾器模式為用戶添加緩存
// 用戶緩存裝飾器
type UserCacheDecorator struct {
}
// 創(chuàng)建一個(gè)裝飾器
func NewUserCacheDecorator() *UserCacheDecorator {
return new(UserCacheDecorator)
}
//
func (UserCacheDecorator) Read(u *User) *User{
// 讀取用戶緩存
if u := GetUserCache(u.Id);u != nil {
如果緩存存在，則返回
return u
}
// 在裝飾器里吨掌，調(diào)用真正的業(yè)務(wù)代碼 - 讀取用戶信息
u.Read()
// 設(shè)置用戶緩存
SetUserCache(u)
}
func main() {
user := New()
user.Id= 123
// 通過裝飾器添加緩存
user = NewUserCacheDecorator().Read(user)
}
- 進(jìn)階版半抱，多個(gè)裝飾器去修飾讀取用戶信息的功能
// 用戶
type User struct {
Id int
}
func New() *User {
return new(User)
}
// 查詢用戶信息
func (u *User) Read(uid int) *User {
u.Id = uid
fmt.Println("讀取數(shù)據(jù)庫信息", uid)
return u
}
// 用戶裝飾器抽象接口
type userDecoratorInter interface {
Read(uid int) *User
}
// 緩存用戶信息的裝飾器
type UserCacheDecorator struct {
u userDecoratorInter
}
func NewUserCacheDecorator(u userDecoratorInter) userDecoratorInter {
de := new(UserCacheDecorator)
de.u = u
return de
}
func (decorator *UserCacheDecorator) Read(uid int) *User {
// 讀取用戶緩存
if u := GetUserCache(uid); u != nil {
// 如果緩存存在，則返回
return u
}
// 讀取用戶信息
user := decorator.u.Read(uid)
// 設(shè)置用戶緩存
SetUserCache(user)
return user
}
// 用戶日志的裝飾器
type UserLogDecorator struct {
u userDecoratorInter
}
func NewUserLogDecorator(u userDecoratorInter) userDecoratorInter {
de := new(UserLogDecorator)
de.u = u
return de
}
func (decorator *UserLogDecorator) Read(uid int) *User {
// 讀取用戶信息
user := decorator.u.Read(uid)
// 打印用戶行為日志
fmt.Println("日志：用戶讀取信息...", uid)
return user
}
// 獲取用戶緩存
func GetUserCache(uid int) *User {
fmt.Println("獲取用戶緩存", uid)
return nil
}
// 設(shè)置用戶緩存
func SetUserCache(u *User) {
fmt.Println("設(shè)置用戶緩存", u)
}
func main() {
uid := 123
// 創(chuàng)建用戶實(shí)例
user := New()
var decorator userDecoratorInter
// 用戶緩存裝飾器
decorator = NewUserCacheDecorator(user)
// 用戶日志裝飾器
decorator = NewUserLogDecorator(decorator)
// more decorator...
// 讀取用戶信息
decorator.Read(uid)
}
代碼對(duì)比
引入裝飾器的原因是膜宋，在不修改原來代碼的情況下代虾，對(duì)原有的功能進(jìn)行擴(kuò)展。在上面的例子中激蹲，我們要為用戶添加緩存功能棉磨，但并不希望在原有的代碼上修改，所以引入了緩存裝飾器学辱，同時(shí)還能擴(kuò)展更多的裝飾器乘瓤，如日志裝飾器等，這樣能讓代碼更靈活策泣。
舉例2
gin的中間件
舉例1可能說的不是很清楚衙傀，我們來看一下gin的中間件
gin的中間件其實(shí)也是使用裝飾器的來實(shí)現(xiàn)的
{
// 這是gin路由
v1 := r.Group("/v1")
v1.POST("/point", Auth, ReceivePoint) // 假設(shè)，給用戶加個(gè)積分
}
func Auth(c *gin.Context){
// 校驗(yàn)權(quán)限
}
func ReceivePoint(c *gin.Context){
// 處理邏輯
}
gin中間件執(zhí)行流程
下面簡化一下gin中間件的執(zhí)行流程萨咕，方便閱讀
// 1.添加中間件统抬，在我們的路由層添加中間件函數(shù)，并與路由綁定
handlers := []gin.HandlerFunc{
Auth, ReceivePoint
}
// 2.生成c危队，這里的c是由gin生成聪建，每個(gè)http request就會(huì)又一個(gè)c
c = &gin.Context{}
// 3.執(zhí)行中間件
for _,handler := range handlers {
// 剛才的 Auth, ReceivePoint函數(shù)都在這里按順序執(zhí)行
handler(c)
}
上面的ReceivePoint()函數(shù)就是業(yè)務(wù)邏輯，它在這里是被裝飾的功能茫陆，而Auth()函數(shù)是裝飾功能金麸。
我們可以這樣理解，接口原有的功能就是給用戶添加積分簿盅，即ReceivePoint()挥下。但我希望在加積分之前，加一個(gè)驗(yàn)證token的功能桨醋，所以這里擴(kuò)展了Auth()函數(shù)棚瘟。而Auth和ReceivePoint之間代碼是相互獨(dú)立的，只是依賴了gin.Context喜最。
gin源碼
gin中間件的數(shù)據(jù)類型
只要實(shí)現(xiàn)了HandlerFunc類型的函數(shù)偎蘸，都可以作為gin中間件，如上述的Auth, ReceivePoint函數(shù)
// HandlerFunc defines the handler used by gin middleware as return value.
type HandlerFunc func(*Context)
gin的Next函數(shù)
調(diào)用中間件的執(zhí)行，基本是在Next()函數(shù)里面禀苦，同時(shí)它還可以控制中間件的執(zhí)行順序
// Next should be used only inside middleware.
// It executes the pending handlers in the chain inside the calling handler.
// See example in GitHub.
func (c *Context) Next() {
c.index++
for c.index < int8(len(c.handlers)) {
c.handlers[c.index](c)
c.index++
}
}
裝飾器使用場景
緩存：讀寫數(shù)據(jù)的緩存
gin的中間件：權(quán)限校驗(yàn)器、打印請(qǐng)求日志等
總結(jié)
優(yōu)點(diǎn)
- 裝飾器可以動(dòng)態(tài)擴(kuò)展一個(gè)實(shí)現(xiàn)類的功能遂鹊，而不是在原有的功能代碼上做修改振乏，符合開放封閉原則。
- 裝飾器和被裝飾器之間可以獨(dú)立發(fā)展秉扑，不會(huì)相互耦合慧邮。
缺點(diǎn)：
- 多層裝飾設(shè)計(jì)起來會(huì)比較復(fù)雜；
