title: 装饰器模式
date: 2021-11-05 13:58:21
前言
装饰器模式是一种结构型设计模式，它可以向现有对象动态地添加任意功能，而不改变其原本结构 。
面向对象中的装饰器
由图可知，具体装饰器类Concrete Decorators继承Component接口类，与具体部件类Concrete Component一样拥有execute方法。但不同在于，Concrete Decorators的execute方法，是在被装饰对象wrappee的execute方法的基础上添加额外功能。而这个被装饰对象wrappee，既可以是具体部件类，也可以是装饰器类。
使用时，用户可用多层装饰器来包裹部件，整体呈一个链式关系：
c = new ConcreteDecoratorA(new ConcreteDecoratorB(new ConcreteComponent()))
c.execute()
最终调用execute方法时，会依次调用ConcreteDecoratorA.execute() → ConcreteDecoratorB.execute() → ConcreteComponent.execute()。
举例
有一家奶茶店，提供多种类型的奶茶：奶青、乌龙奶茶、椰奶奶茶等等。当然，奶茶也可以加料，配料有椰果、珍珠、仙草等等。刚开始售卖奶茶时，奶茶店将奶茶与配料捆绑在一起，就会出现一份椰果的乌龙奶茶、一份珍珠的椰奶奶茶、一份椰果与一份珍珠的椰奶奶茶等，这样不仅使奶茶种类变得臃肿，还丧失了灵活性。顾客体验很差，生意自然就不好。
但好巧不巧，老板无意中学习到了装饰器模式，幡然醒悟，将奶茶与配料拆开，让顾客先选择奶茶，再添加任意配料。如此，顾客就有非常自由且丰富的选择。顾客高兴了，生意自然就好起来了，奶茶店也有了好盼头。
在这个例子中，奶茶就是Component接口类，配料就是Base Decorator类。一杯奶茶Concrete Component被生产出来后，可以向其中添加任意类型和数量的配料Concrete Decorators。
自问自答
为什么不把Decorators作为Component类的一个数组属性？然后在execute时依次调用Decorators中 的方法呢？
首先，这样需要修改Component类的结构和内容。而在实际中，往往是先有Component再有Decorator，甚至Component是不允许修改的。
其次，缺乏灵活性。不同Decorator可能有不同的行为，有些Decorator想在execute方法被调用之前做处理，有些则想在之后做处理。
而装饰器模式既不用修改被装饰对象，又保证了灵活性。
面向过程中的装饰器
面向对象通常离我们较远，而真正让我领会到装饰器模式厉害之处的，是在面向过程的编程中。
Python中的装饰器
编写函数时我总有一个习惯，在函数的开头打印函数开始与函数参数，并在函数结尾打印函数结束与函数返回值。如此，打印输出的逻辑顺序较为清晰，就可以较为轻松地进行调试。
def funcA(s):
print("++++++ funA begin ++++++")
print(s)
...
print(ret)
print("------ funA end ------")
return ret
funcA(1)
但是，如果每个函数都添加这些步骤，重复性又太高，代码将充满坏味道。有一种方法是定义专门的函数如下：
# args 参数数组，kwargs 参数字典
def func_log(func, *args, **kwargs):
print(f"++++++ {func.__name__} begin ++++++")
print(*args, **kwargs)
ret = func(*args, **kwargs)
print(ret)
print(f"------ {func.__name__} end ------")
return ret
def funcA(s):
...
# old: funcA(1)
func_log(funcA, 1)
这样虽然能复用，但原来通过funcA(1)，现在要通过func_log(funcA, 1)的形式调用。改变了代码的原本结构 ，这是我们不想看到的。
于是，装饰器模式登场了。装饰器模式的本质在于：传入一种类型的变量或对象，在不改变其原有结构的基础上进行装饰加工，最终返回相同类型的变量或对象。
def log_decorator(func):
def wrapper(*args, **kwargs):
print(f"++++++ {func.__name__} begin ++++++")
print(f"===> args:{args}, kwargs:{kwargs}")
ret = func(*args, **kwargs)
print(f"<=== return:{ret}")
print(f"------ {func.__name__} end ------")
return ret
return wrapper
def funcA(s):
...
funcA = log_decorator(funcA) # 使用装饰器装饰
...
funcA(1)
使用装饰器后，既能在函数的调用前后添加额外功能，又不会改变函数的内容和调用方式。这已经非常完美了，但还能更完美。在python中，还提供了装饰器语法糖@，使装饰器的使用更加方便：
def log_decorator(func):
def wrapper(*args, **kwargs):
print(f"++++++ {func.__name__} begin ++++++")
print(f"===> args:{args}, kwargs:{kwargs}")
ret = func(*args, **kwargs)
print(f"<=== return:{ret}")
print(f"------ {func.__name__} end ------")
return ret
return wrapper
@log_decorator # 使用装饰器装饰
def funcA(s):
...
funcA(1)
Go中的装饰器
只要在一门语言中函数是一等公民，那这门语言就可以使用过程式的装饰器。因而，Go语言也可以编写过程式的装饰器。
package main
import (
"log"
"runtime"
"reflect"
)
type Func func(s string) string
func getFuncName(i interface{}) string {
return runtime.FuncForPC(reflect.ValueOf(i).Pointer()).Name()
}
func logDecorator(fn Func) Func {
return func(s string) string {
funcName := getFuncName(fn)
log.Printf("===> %s arg: %v\n", funcName, s)
ret := fn(s)
log.Printf("<=== %s ret: %v\n", funcName, ret)
return ret
}
}
func funcA(s string) string {
s = "hello " + s
return s
}
func main() {
fn := logDecorator(funcA)
fn("decorator")
}
但是，Go语言是一门强类型语言，它无法做到python那样将一个装饰器应用到任意函数上。在Go语言中，只能对同一类型的函数（参数与返回值都相同）编写专门的装饰器，这与面向对象的装饰器相似。同时，它也暂不支持装饰器语法糖。
总结
装饰器模式，尤其是面向过程的装饰器，可以将许多小功能（如打印日志、计算运行时间、参数预处理等）作为装饰器，灵活地组合在一起，大大提高代码的复用性。
其实，装饰器模式这种“只提供最基础本体，而将附加功能作为装饰器 ”的思想，不仅适用于代码编写，还适用于方方面面。比如，当今后端框架越来越趋于小而轻，而不是大而重，框架只需提供最基础的功能，而附加功能可通过插件的形式进行补充，这样就能使得用户的选择更加灵活多样。再比如，奶茶中的配料、烹饪时的佐料等等，都是装饰器模式思想的体现。
