极客时间已完结课程限时免费阅读

34 | 编程范式游记（5）- 修饰器模式

34 | 编程范式游记（5）- 修饰器模式-极客时间

34 | 编程范式游记（5）- 修饰器模式

2018-01-25 陈皓 来自北京
《左耳听风》
课程介绍

讲述：杨超

时长11:09大小10.19M

你好，我是陈皓，网名左耳朵耗子。
在上一讲中，我们领略了函数式编程的趣味和魅力，主要讲了函数式编程的主要技术。还记得有哪些吗？递归、Map、Reduce、Filter 等，并利用 Python 的 Decorator 和 Generator 功能，将多个函数组合成了管道。
此时，你心中可能会有个疑问，这个 decorator 又是怎样工作的呢？这就是本文中要讲述的内容，“Decorator 模式”，又叫“修饰器模式”，或是“装饰器模式”。

Python 的 Decorator

Python 的 Decorator 在使用上和 Java 的 Annotation（以及 C# 的 Attribute）很相似，就是在方法名前面加一个 @XXX 注解来为这个方法装饰一些东西。但是，Java/C# 的 Annotation 也很让人望而却步，太过于复杂了。你要玩它，需要先了解一堆 Annotation 的类库文档，感觉几乎就是在学另外一门语言。
而 Python 使用了一种相对于 Decorator Pattern 和 Annotation 来说非常优雅的方法，这种方法不需要你去掌握什么复杂的 OO 模型或是 Annotation 的各种类库规定，完全就是语言层面的玩法：一种函数式编程的技巧。
这是我最喜欢的一个模式了，也是一个挺好玩儿的东西，这个模式动用了函数式编程的一个技术——用一个函数来构造另一个函数。
好了，我们先来点感性认识，看一个 Python 修饰器的 Hello World 代码。
def hello(fn):
def wrapper():
print "hello, %s" % fn.__name__
fn()
print "goodbye, %s" % fn.__name__
return wrapper
@hello
def Hao():
print "i am Hao Chen"
Hao()
代码的执行结果如下：
$ python hello.py
hello, Hao
i am Hao Chen
goodbye, Hao
你可以看到如下的东西：
函数 Hao 前面有个 @hello 的“注解”，hello 就是我们前面定义的函数 hello；
在 hello 函数中，其需要一个 fn 的参数（这就是用来做回调的函数）；
hello 函数中返回了一个 inner 函数 wrapper，这个 wrapper函数回调了传进来的 fn，并在回调前后加了两条语句。
对于 Python 的这个 @注解语法糖（Syntactic sugar）来说，当你在用某个 @decorator 来修饰某个函数 func 时，如下所示:
@decorator
def func():
pass
其解释器会解释成下面这样的语句：
func = decorator(func)
嘿！这不就是把一个函数当参数传到另一个函数中，然后再回调吗？是的。但是，我们需要注意，那里还有一个赋值语句，把 decorator 这个函数的返回值赋值回了原来的 func。
我们再来看一个带参数的玩法：
def makeHtmlTag(tag, *args, **kwds):
def real_decorator(fn):
css_class = " class='{0}'".format(kwds["css_class"]) \
if "css_class" in kwds else ""
def wrapped(*args, **kwds):
return "<"+tag+css_class+">" + fn(*args, **kwds) + "</"+tag+">"
return wrapped
return real_decorator
@makeHtmlTag(tag="b", css_class="bold_css")
@makeHtmlTag(tag="i", css_class="italic_css")
def hello():
return "hello world"
print hello()
# 输出：
# <b class='bold_css'><i class='italic_css'>hello world</i></b>
在上面这个例子中，我们可以看到：makeHtmlTag有两个参数。所以，为了让 hello = makeHtmlTag(arg1, arg2)(hello) 成功， makeHtmlTag 必需返回一个 decorator（这就是为什么我们在 makeHtmlTag 中加入了 real_decorator()）。
这样一来，我们就可以进入到 decorator 的逻辑中去了——decorator 得返回一个 wrapper，wrapper 里回调 hello。看似那个 makeHtmlTag() 写得层层叠叠，但是，已经了解了本质的我们觉得写得很自然。
我们再来看一个为其它函数加缓存的示例：
from functools import wraps
def memoization(fn):
cache = {}
miss = object()
@wraps(fn)
def wrapper(*args):
result = cache.get(args, miss)
if result is miss:
result = fn(*args)
cache[args] = result
return result
return wrapper
@memoization
def fib(n):
if n < 2:
return n
return fib(n - 1) + fib(n - 2)
上面这个例子中，是一个斐波那契数列的递归算法。我们知道，这个递归是相当没有效率的，因为会重复调用。比如：我们要计算 fib(5)，于是其分解成 fib(4) + fib(3)，而 fib(4) 分解成 fib(3) + fib(2)，fib(3) 又分解成fib(2) + fib(1)……你可以看到，基本上来说，fib(3)、fib(2)、fib(1)在整个递归过程中被调用了至少两次。
而我们用 decorator，在调用函数前查询一下缓存，如果没有才调用，有了就从缓存中返回值。一下子，这个递归从二叉树式的递归成了线性的递归。wraps 的作用是保证 fib 的函数名不被 wrapper 所取代。
除此之外，Python 还支持类方式的 decorator。
class myDecorator(object):
def __init__(self, fn):
print "inside myDecorator.__init__()"
self.fn = fn
def __call__(self):
self.fn()
print "inside myDecorator.__call__()"
@myDecorator
def aFunction():
print "inside aFunction()"
print "Finished decorating aFunction()"
aFunction()
# 输出：
# inside myDecorator.__init__()
# Finished decorating aFunction()
# inside aFunction()
# inside myDecorator.__call__()
上面这个示例展示了，用类的方式声明一个 decorator。我们可以看到这个类中有两个成员：
一个是__init__()，这个方法是在我们给某个函数 decorate 时被调用，所以，需要有一个 fn 的参数，也就是被 decorate 的函数。
一个是__call__()，这个方法是在我们调用被 decorate 的函数时被调用的。
从上面的输出中，可以看到整个程序的执行顺序，这看上去要比“函数式”的方式更易读一些。
我们来看一个实际点的例子，下面这个示例展示了通过 URL 的路由来调用相关注册的函数示例：
class MyApp():
def __init__(self):
self.func_map = {}
def register(self, name):
def func_wrapper(func):
self.func_map[name] = func
return func
return func_wrapper
def call_method(self, name=None):
func = self.func_map.get(name, None)
if func is None:
raise Exception("No function registered against - " + str(name))
return func()
app = MyApp()
@app.register('/')
def main_page_func():
return "This is the main page."
@app.register('/next_page')
def next_page_func():
return "This is the next page."
print app.call_method('/')
print app.call_method('/next_page')
注意：上面这个示例中 decorator 类不是真正的 decorator，其中也没有__call__()，并且，wrapper 返回了原函数。所以，原函数没有发生任何变化。

Go 语言的 Decorator

Python 有语法糖，所以写出来的代码比较酷。但是对于没有修饰器语法糖这类语言，写出来的代码会是怎么样的？我们来看一下 Go 语言的代码。
还是从一个 Hello World 开始。
package main
import "fmt"
func decorator(f func(s string)) func(s string) {
return func(s string) {
fmt.Println("Started")
f(s)
fmt.Println("Done")
}
}
func Hello(s string) {
fmt.Println(s)
}
func main() {
decorator(Hello)("Hello, World!")
}
可以看到，我们动用了一个高阶函数 decorator()，在调用的时候，先把 Hello() 函数传进去，然后其返回一个匿名函数。这个匿名函数中除了运行了自己的代码，也调用了被传入的 Hello() 函数。
这个玩法和 Python 的异曲同工，只不过，Go 并不支持像 Python 那样的 @decorator 语法糖。所以，在调用上有些难看。当然，如果要想让代码容易读一些，你可以这样：
hello := decorator(Hello)
hello("Hello")
我们再来看一个为函数 log 消耗时间的例子：
type SumFunc func(int64, int64) int64
func getFunctionName(i interface{}) string {
return runtime.FuncForPC(reflect.ValueOf(i).Pointer()).Name()
}
func timedSumFunc(f SumFunc) SumFunc {
return func(start, end int64) int64 {
defer func(t time.Time) {
fmt.Printf("--- Time Elapsed (%s): %v ---\n",
getFunctionName(f), time.Since(t))
}(time.Now())
return f(start, end)
}
}
func Sum1(start, end int64) int64 {
var sum int64
sum = 0
if start > end {
start, end = end, start
}
for i := start; i <= end; i++ {
sum += i
}
return sum
}
func Sum2(start, end int64) int64 {
if start > end {
start, end = end, start
}
return (end - start + 1) * (end + start) / 2
}
func main() {
sum1 := timedSumFunc(Sum1)
sum2 := timedSumFunc(Sum2)
fmt.Printf("%d, %d\n", sum1(-10000, 10000000), sum2(-10000, 10000000))
}
关于上面的代码：
有两个 Sum 函数，Sum1() 函数就是简单地做个循环，Sum2() 函数动用了数据公式。（注意：start 和 end 有可能有负数的情况。）
代码中使用了 Go 语言的反射机制来获取函数名。
修饰器函数是 timedSumFunc()。
再来看一个 HTTP 路由的例子：
func WithServerHeader(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Println("--->WithServerHeader()")
w.Header().Set("Server", "HelloServer v0.0.1")
h(w, r)
}
}
func WithAuthCookie(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Println("--->WithAuthCookie()")
cookie := &http.Cookie{Name: "Auth", Value: "Pass", Path: "/"}
http.SetCookie(w, cookie)
h(w, r)
}
}
func WithBasicAuth(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Println("--->WithBasicAuth()")
cookie, err := r.Cookie("Auth")
if err != nil || cookie.Value != "Pass" {
w.WriteHeader(http.StatusForbidden)
return
}
h(w, r)
}
}
func WithDebugLog(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Println("--->WithDebugLog")
r.ParseForm()
log.Println(r.Form)
log.Println("path", r.URL.Path)
log.Println("scheme", r.URL.Scheme)
log.Println(r.Form["url_long"])
for k, v := range r.Form {
log.Println("key:", k)
log.Println("val:", strings.Join(v, ""))
}
h(w, r)
}
}
func hello(w http.ResponseWriter, r *http.Request) {
log.Printf("Received Request %s from %s\n", r.URL.Path, r.RemoteAddr)
fmt.Fprintf(w, "Hello, World! "+r.URL.Path)
}
上面的代码中，我们写了多个函数。有写 HTTP 响应头的，有写认证 Cookie 的，有检查认证 Cookie 的，有打日志的……在使用过程中，我们可以把其嵌套起来使用，在修饰过的函数上继续修饰，这样就可以拼装出更复杂的功能。
func main() {
http.HandleFunc("/v1/hello", WithServerHeader(WithAuthCookie(hello)))
http.HandleFunc("/v2/hello", WithServerHeader(WithBasicAuth(hello)))
http.HandleFunc("/v3/hello", WithServerHeader(WithBasicAuth(WithDebugLog(hello))))
err := http.ListenAndServe(":8080", nil)
if err != nil {
log.Fatal("ListenAndServe: ", err)
}
}
当然，如果一层套一层不好看的话，我们可以使用 pipeline 的玩法，需要先写一个工具函数——用来遍历并调用各个 decorator：
type HttpHandlerDecorator func(http.HandlerFunc) http.HandlerFunc
func Handler(h http.HandlerFunc, decors ...HttpHandlerDecorator) http.HandlerFunc {
for i := range decors {
d := decors[len(decors)-1-i] // iterate in reverse
h = d(h)
}
return h
}
然后，我们就可以像下面这样使用了。
http.HandleFunc("/v4/hello", Handler(hello,
WithServerHeader, WithBasicAuth, WithDebugLog))
这样的代码是不是更易读了一些？pipeline 的功能也就出来了。
不过，对于 Go 的修饰器模式，还有一个小问题——好像无法做到泛型，就像上面那个计算时间的函数一样，它的代码耦合了需要被修饰的函数的接口类型，无法做到非常通用。如果这个事解决不了，那么，这个修饰器模式还是有点不好用的。
因为 Go 语言不像 Python 和 Java，Python 是动态语言，而 Java 有语言虚拟机，所以它们可以干许多比较变态的事儿，然而 Go 语言是一个静态的语言，这意味着其类型需要在编译时就要搞定，否则无法编译。不过，Go 语言支持的最大的泛型是 interface{}，还有比较简单的 Reflection 机制，在上面做做文章，应该还是可以搞定的。
废话不说，下面是我用 Reflection 机制写的一个比较通用的修饰器（为了便于阅读，我删除了出错判断代码）。
func Decorator(decoPtr, fn interface{}) (err error) {
var decoratedFunc, targetFunc reflect.Value
decoratedFunc = reflect.ValueOf(decoPtr).Elem()
targetFunc = reflect.ValueOf(fn)
v := reflect.MakeFunc(targetFunc.Type(),
func(in []reflect.Value) (out []reflect.Value) {
fmt.Println("before")
out = targetFunc.Call(in)
fmt.Println("after")
return
})
decoratedFunc.Set(v)
return
}
上面的代码动用了 reflect.MakeFunc() 函数制作出了一个新的函数，其中的 targetFunc.Call(in) 调用了被修饰的函数。关于 Go 语言的反射机制，推荐官方文章——《The Laws of Reflection》，在这里我不多说了。
上面这个 Decorator() 需要两个参数：
第一个是出参 decoPtr ，就是完成修饰后的函数。
第二个是入参 fn ，就是需要修饰的函数。
这样写是不是有些二？的确是的。不过，这是我个人在 Go 语言里所能写出来的最好的代码了。如果你知道更优雅的写法，请你一定告诉我！
好的，让我们来看一下使用效果。首先，假设我们有两个需要修饰的函数：
func foo(a, b, c int) int {
fmt.Printf("%d, %d, %d \n", a, b, c)
return a + b + c
}
func bar(a, b string) string {
fmt.Printf("%s, %s \n", a, b)
return a + b
}
然后，我们可以这样做：
type MyFoo func(int, int, int) int
var myfoo MyFoo
Decorator(&myfoo, foo)
myfoo(1, 2, 3)
你会发现，使用 Decorator() 时，还需要先声明一个函数签名，感觉好傻啊。一点都不泛型，不是吗？谁叫这是有类型的静态编译的语言呢？
嗯。如果你不想声明函数签名，那么也可以这样：
mybar := bar
Decorator(&mybar, bar)
mybar("hello,", "world!")
好吧，看上去不是那么得漂亮，但是 it does work。看样子 Go 语言目前本身的特性无法做成像 Java 或 Python 那样，对此，我们只能多求 Go 语言多放糖了！

小结

好了，讲了那么多的例子，看了那么多的代码，我估计你可能有点晕，让我们来做个小结吧。
通过上面 Python 和 Go 修饰器的例子，我们可以看到，所谓的修饰器模式其实是在做下面的几件事。
表面上看，修饰器模式就是扩展现有的一个函数的功能，让它可以干一些其他的事，或是在现有的函数功能上再附加上一些别的功能。
除了我们可以感受到函数式编程下的代码扩展能力，我们还能感受到函数的互相和随意拼装带来的好处。
但是深入看一下，我们不难发现，Decorator 这个函数其实是可以修饰几乎所有的函数的。于是，这种可以通用于其它函数的编程方式，可以很容易地将一些非业务功能的、属于控制类型的代码给抽象出来（所谓的控制类型的代码就是像 for-loop，或是打日志，或是函数路由，或是求函数运行时间之类的非业务功能性的代码）。
以下是《编程范式游记》系列文章的目录，方便你了解这一系列内容的全貌。
01 | 编程范式游记：起源
02 | 编程范式游记：泛型编程
03 | 编程范式游记：类型系统和泛型的本质
04 | 编程范式游记：函数式编程
05 | 编程范式游记：修饰器模式
06 | 编程范式游记：面向对象编程
07 | 编程范式游记：基于原型的编程范式
08 | 编程范式游记：Go 语言的委托模式
09 | 编程范式游记：编程的本质
10 | 编程范式游记：逻辑编程范式
11 | 编程范式游记：程序世界里的编程范式
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享

赞 23

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
33 | 编程范式游记（4）- 函数式编程
下一篇
35 | 编程范式游记（6）- 面向对象编程
unpreview
 写留言

精选留言(27)

  • 楊_宵夜
    2018-02-02
    越看越觉得装饰器模式是属于AOP思想的一种实现🤔。
    共 5 条评论
    40
  • 陈华
    2019-06-20
    ...感觉还是转行算了....，
    共 1 条评论
    21
  • minghu6
    2018-02-14
    其实Java装饰器和Python装饰器还是差别挺大的，Python装饰器是一个高阶函数，Java的则真的是"注解"，只是起到一个打标签的作用，还要另外的类来检查特定标签进行特定处理。
    共 1 条评论
    14
  • 麻花快跑
    2018-01-25
    耗子叔，我看你博客和文章很久了，从coolshell就开始了，现在也快30了，但是越来越焦虑，他们都说是30岁程序员的普遍情况，希望耗子叔能以过来人的身份写下这方面的文章，为我们指点下迷路
    共 2 条评论
    11
  • 浩子
    2018-01-25
    耗子哥，文章写的很有意思。最近也在相继学习Go语言。 不过我很纠结，我是一名.net的技术主管，最近想开拓其他语言的方向。可是却不知道从何下手，比较感兴趣的有Go，Java，Python。可是时间总是有限的。 不知道从哪面方面进行深入研究。
    共 2 条评论
    7
  • 少盐
    2018-12-15
    基本没看懂，后面的总结基本知道装饰器是干嘛的
    6
  • seedjyh
    2021-10-19
    理解python的函数型装饰器，关键就是分清3个函数。 - 被装饰的函数 raw_fn - 装饰后的函数 new_fn - 执行装饰的函数 decoractor_fn 其中，raw_fn 和 new_fn 的函数签名（参数和返回值）是相同的，就是一连串@之后真正手写def的那个函数。 decoractor_fn 的参数是 raw_fn，在内部定义new_fn并返回之。 至于带参数的装饰器，其实就是产生装饰器的工厂，本身并不是装饰器。 decoractor_factory的参数可以随便写，其内部定义一个decoractor_fn并返回。 类模式的装饰器有点像C++的仿函数。 Golang的装饰器，在框架echo的middleware这里体现得淋漓尽致。
    展开
    6
  • edisonhuang
    2019-06-21
    通过装饰器，我们很容易的给代码添加一些功能，附加执行一些操作。然后深入之后发现装饰器可以修饰任何函数，加不同函数随意组合和拼装往往会带来一些神奇的效果，恰如linux的编码哲学，一个工具只做一件事并把这件事做到极致。 通过装饰器的封装，我们可以把很多业务逻辑，重复代码给消除，从而优化代码
    3
  • 恒
    2018-09-19
    go语言的第一个例子让我联想到java的静态代理，后面反射的例子让我联想到java的动态代理
    3
  • 拉欧
    2019-05-27
    这一章的内容真带劲
    2
  • 杨智晓 ✟
    2018-11-16
    哎，Go语言的语法真是看着别扭，虽然知道Go强劲
    共 2 条评论
    2
  • 亮出
    2018-07-26
    编程的例子，有github么
    2
  • 秋天
    2018-04-26
    python和go基本语法要看看上面有的函数例子，没看懂。
    2
  • 靠人品去赢
    2021-04-14
    第一个python装饰器代码，python 3.X版本，写法有点不同可能，可以试试我的，看看可不可以直接运行： def hello(fn): def wrapper(): print("hello, %s" % fn.__name__) fn() print("goodbye, %s" % fn.__name__) return wrapper @hello def Hao(): print("i am Hao Chen") Hao()
    展开
    共 1 条评论
    1
  • Marvichov
    2020-07-11
    感觉本质还是函数式编程里面的closure...函数式里面都是immutable的，所以closure是很安全的...但是python和go这类的语言是有状态的，debug closure的时候就很痛苦...比如你传了一个python dict或者go的pointer...wrapped function很可能就会产生让人头痛的side effect...大家用的时候又喜欢滥用...总体感觉，感觉decorator就是动态语言的generics...
    1
  • Edward Lee
    2020-04-30
    函数式编程中的 Decorator 用法，我在很多程序代码或脚本中看到过，原来这种写法有个名字叫 Decorator，像 Pipeline 一样连接所有的函数。有一种贯通已有编程认知的感觉，就像零碎的知识被串联在一起。
    1
  • 靠人品去赢
    2021-04-14
    装饰模式突然讲几个语言的实现串在一起对比，感觉明白了点，之前只关注细节没有考虑到后面的设计模式。
  • 爱学习的大叔
    2020-10-31
    感觉有点像.net 里边的面向切面(AOP),给流程上节外生枝，做点别的事情。
  • 小文同学
    2020-10-26
    关于 Go 的修饰器后半部分(正文最后四分之一)，我还没完全看懂，可能是因为缺少 Go 的语言基础。但 Python 比较熟悉，修饰器部分也能够明白。 自己同事使用 Python 的修饰器，成功做了一些 动态加载函数 的功能，可谓是让后期我们的某个环节的工作效率提高了数倍。从十多分钟的操作，改写为10s的工作。
  • 你为啥那么牛
    2020-09-05
    从来没学过python，通过这篇文章，我学会了。而且，全部看懂了。