装饰器模式

发表于 分类于 ， 阅读次数： 本文字数： 3.8k

前言

装饰器模式是一种结构型设计模式，它可以向现有对象动态地添加任意功能，而不改变其原本结构 。

面向对象中的装饰器

1

由图可知，具体装饰器类Concrete Decorators继承Component接口类，与具体部件类Concrete Component一样拥有execute方法。但不同在于，Concrete Decorators的execute方法，是在被装饰对象wrappee的execute方法的基础上添加额外功能。而这个被装饰对象wrappee，既可以是具体部件类，也可以是装饰器类。

使用时，用户可用多层装饰器来包裹部件，整体呈一个链式关系：

1
2
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中的装饰器

编写函数时我总有一个习惯，在函数的开头打印函数开始与函数参数，并在函数结尾打印函数结束与函数返回值。如此，打印输出的逻辑顺序较为清晰，就可以较为轻松地进行调试。

1
2
3
4
5
6
7
8
9
10
11
def funcA(s):
    print("++++++ funA begin ++++++")
    print(s)

    ...

    print(ret)
    print("------ funA end ------")
    return ret

funcA(1)

但是，如果每个函数都添加这些步骤，重复性又太高，代码将充满坏味道。有一种方法是定义专门的函数如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 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)的形式调用。改变了代码的原本结构 ，这是我们不想看到的。

于是，装饰器模式登场了。装饰器模式的本质在于：传入一种类型的变量或对象，在不改变其原有结构的基础上进行装饰加工，最终返回相同类型的变量或对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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中，还提供了装饰器语法糖@，使装饰器的使用更加方便：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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语言也可以编写过程式的装饰器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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语言中，只能对同一类型的函数（参数与返回值都相同）编写专门的装饰器，这与面向对象的装饰器相似。同时，它也暂不支持装饰器语法糖。

总结

装饰器模式，尤其是面向过程的装饰器，可以将许多小功能（如打印日志、计算运行时间、参数预处理等）作为装饰器，灵活地组合在一起，大大提高代码的复用性。

其实，装饰器模式这种“只提供最基础本体，而将附加功能作为装饰器 ”的思想，不仅适用于代码编写，还适用于方方面面。比如，当今后端框架越来越趋于小而轻，而不是大而重，框架只需提供最基础的功能，而附加功能可通过插件的形式进行补充，这样就能使得用户的选择更加灵活多样。再比如，奶茶中的配料、烹饪时的佐料等等，都是装饰器模式思想的体现。