假以时日,我相信装饰器一定会成为Python这门编程语言一个更加强大的功能。到目前为止,我觉得到我所看到的有关介绍Python装饰器的文章都或多或少地会让人觉得困惑,所以在这儿尝试看能否修正这些问题。
首先,大家需要明白的是使用 装饰器
这个词可能会有不少让大家担忧的地方,因为它很容易和 设计模式 这本书里面的 装饰器模式
发生混淆。曾经一度考虑给这个新的功能取一些其它的 术语
名称,但是 装饰器
最终还是胜出了。
的确,你可以使用python装饰器来实现 装饰器模式
,但这绝对是它很小的一部分功能,有点暴殄天物。对于python装饰器,我觉得它是最接近 宏
的存在。
宏
有有着非常悠久的历史,不过大多数人可能会有使用C语言预处理宏的经验。但是,对于C语言里的宏来说,它存在一些问题,(1)宏并不存在于C语言中,(2)而且宏的行为有时候会有点诡异,而且经常会和C语言的行为不太一致。
为了支持对语言本身的一些元素进行操作,Java和C#都添加了注解。当然他们也都存在一些问题:有时候为了达到自己的目的,你不得不绕过很多的坑。还没完,这些注解特性还会受到这些语言的一些与生俱来的特性的束手束脚(就像Martin Fowler所描述的” Directing “)
稍有不同的是,包括我在内的很多C++程序员已经意识到C++模板的威力,也已经在像使用宏一样在使用这个功能。
很多其他的语言也都包含宏的功能,尽管了解的并不多,我还是愿意大言不惭的说,python装饰器无论在功能的强大还是丰富性方面都和Lisp的宏很相似。
我觉得,这样对 宏
进行描述并不过分:一门编程语言中宏的存在是为了提供操作语言元素本身的能力。这恰恰也是python装饰器能做的事情,它们能够对函数进行修改,也能对这个类进行装饰。相比复杂的 元类
,这也许是大家经常提供一个简单的装饰器的原因吧。
大多数编程语言所提供的能进行自我修改(元编程)的方案都有一个主要的缺点,那就是限制和束缚太多,写着写着有种在写其它语言的错觉。
Python符合Martin Fowler所说的 Enabling 编程语言。所以说,如果你想进行修改操作(元编程),为毛还要弄出一门”不一样“或者”限制多多“的语言呢?为什么不直接抄起python自己咔咔就直接开始干呢?这就是python装饰器能做的。
装饰器能够让你“注入”或者”修改“函数或者类里面的代码(逻辑)。除了更加简单和强大之外,装饰器听起来有点像 AOP面向方面编程
的感觉对吧。举例来说,加入你想在方法的开始或者结束前做一些事情(比如一些类似于权限检查、跟踪、资源加锁等一些面向方面编程里的常规操作)。有了装饰器,你可以这么做:
@entryExit def func1(): print "inside func1()" @entryExit def func2(): print "inside func2()"
函数式装饰器通常会被放在一个函数定义的代码前来应用合格装饰器,比如:
@myDecorator def aFunction(): print "inside aFunction"
当编译器走到这段代码的时候,函数 aFunction
会被编译,编译得到的函数对象会传递给 myDecorator
,装饰器会生成一个新的函数对象来替换原有的函数 aFunction
。
那么,装饰器 myDecorator
的代码实现是怎样的呢?尽管大多数的装饰器入门示例都会写一个函数,但是我发现,相比函数式装饰器, 类式装饰器
能更好的帮助理解,而且它更加强大。
唯一需要确保的是,装饰器返回的对象要是像函数一样能够被调用的,因此 类式装饰器
需要实现 __call__
。
装饰器应该要完成什么工作呢?好吧,它能够做任何事情,不过通常情况下,你可能会期望原有的被传递来的函数在某个地方能够被执行,尽管这不是强制的:
class myDecorator(object): def __init__(self, f): print "inside myDecorator.__init__()" f() # Prove that function definition has completed def __call__(self): print "inside myDecorator.__call__()" @myDecorator def aFunction(): print "inside aFunction()" print "Finished decorating aFunction()" aFunction()
当你执行这段代码的时候,你会看到这样的输出:
inside myDecorator.__init__() inside aFunction() Finished decorating aFunction() inside myDecorator.__call__()
请注意, myDecorator
的构造器实际是在 装饰
函数的时候执行的。我们可以在 __init__()
里面调用函数 f
,能够看到,在装饰器被调用之前,函数调用 f()
就已经完成了。另外,装饰器的构造器能够接收被装饰的方法。一般来讲,我们会捕捉到这个函数对象然后接下来在函数 __call__()
里面调用。 装饰和调用是两个非常清晰明了的不同的步骤 ,这也是我为什么说 类似装饰器
更简单同时也更强大的原因。
当函数 aFunction
被装饰完成然后调用的时候,我们得到了一个完全不同的行为,实际上执行的是 myDecorator.__call__()
的代码逻辑,这是因为”装饰“把原有的代码逻辑用新的返回的逻辑给替换掉了。在我们的例子中, myDecorator
对象替换掉了函数 aFunction
。事实上,在装饰器操作符 @
被加入之前,你不得不做一些比较low的操作来完成同样的事情:
def foo(): pass foo = staticmethod(foo)
因为有了 @
这个装饰器操作符, 你可以非常优雅的得到同样的结果:
@staticmethod def foo(): pass
不过也有不少人因为这一点反对装饰器,不过 @
仅仅是一个很小的语法糖而已,把一个函数对象传递给另外一个函数,然后用返回值替换原有的方法。
我觉着,之所以装饰器会产生这么大的影响是因为这个小小的语法糖完全改变了人们思考编程的方式。的确,通过将它实现成一个编程语言结构,它将”代码应用到代码上面“的思想带到了主流编程思维层面。
现在我们实现一下第一个例子。在这里我们将会做一些很常规的事情,并且会使用这些代码:
class entryExit(object): def __init__(self, f): self.f = f def __call__(self): print "Entering", self.f.__name__ self.f() print "Exited", self.f.__name__ @entryExit def func1(): print "inside func1()" @entryExit def func2(): print "inside func2()" func1() func2()
运行结果是:
Entering func1 inside func1() Exited func1 Entering func2 inside func2() Exited func2
现在我们能够看到,那些被装饰的方法有了“进入”和“离开”的跟踪信息。
构造器存储了通过参数传递进来的函数对象,在调用的方法里,我们用函数对象的 __name__
属性来展示被调用函数的名称,然后调用被装饰的函数自己。
对于装饰器返回结果的约束只有一个,那就是能够被调用,从而它能够合理的替换掉原有的被装饰的那个函数。在上面的这些例子中,我们是将原有的函数用包含有 __call__()
的对象替换的。一个函数对象同样能够被调用,所以我们可以用函数来重写前一个装饰器的例子,像这样:
def entryExit(f): def new_f(): print "Entering", f.__name__ f() print "Exited", f.__name__ return new_f @entryExit def func1(): print "inside func1()" @entryExit def func2(): print "inside func2()" func1() func2() print func1.__name__
函数 new_f()
嵌套定义在 entryExit
的方法体里面,当 entryExit
被调用的时候, new_f()
也会顺理成章地被返回。值得注意的是 new_f()
是一个闭包,捕获了参数变量 f
的值。
当 new_f()
定义完成后,它将会被 entryExit
返回,然后装饰器机制发生作用将结果赋值成被装饰的新方法。
代码 print func1.__name__
的输出结果是 new_f
,因为在装饰发生的过程中,原来的方法已经被替换成了 new_f
,如果对你来说这是一个问题的话,你可以在装饰器返回结果之前修改掉函数的名字:
def entryExit(f): def new_f(): print "Entering", f.__name__ f() print "Exited", f.__name__ new_f.__name__ = f.__name__ return new_f
你可以动态的获取函数的信息包括那些你做的更改,这在python里面非常有用。
现在你已经基本有了一个概念,你可以在 这里 找到更多装饰器的例子,这些例子都是使用的类式装饰器,不是函数式装饰器。
在这篇文章中,我故意没有涉及到带参数的被装饰方法,我们下回分解。
【注】“Directing”和“Enabling”是Martin Fowler总结的两种软件开发态度,简单描述下就是:“大部分的开发人员可能比较菜,需要创建约束让开发人员少犯错误,更加规范” vs “让开发人员自己负责,更加自由,当然自己犯的错含着泪也要自己搞定”。
原文地址: Decorators I: Introduction to Python Decorators