装饰器 vs 装饰器模式
首先，大家需要明白的是使用装饰器这个词可能会有不少让大家担忧的地方，因为它很容易和设计模式这本书里面的装饰器模式发生混淆。曾经一度考虑给这个新的功能取一些其它的术语名称，但是装饰器最终还是胜出了。
的确，你可以使用python装饰器来实现装饰器模式，但这绝对是它很小的一部分功能，有点暴殄天物。对于python装饰器，我觉得它是最接近宏的存在。
宏的历史
宏有有着非常悠久的历史，不过大多数人可能会有使用C语言预处理宏的经验。但是，对于C语言里的宏来说，它存在一些问题，(1)宏并不存在于C语言中，(2)而且宏的行为有时候会有点诡异，而且经常会和C语言的行为不太一致。
为了支持对语言本身的一些元素进行操作，Java和C#都添加了注解。当然他们也都存在一些问题：有时候为了达到自己的目的，你不得不绕过很多的坑。还没完，这些注解特性还会受到这些语言的一些与生俱来的特性的束手束脚（就像Martin Fowler所描述的 “Directing”）
稍有不同的是，包括我在内的很多C++程序员已经意识到C++模板的威力，也已经在像使用宏一样在使用这个功能。
很多其他的语言也都包含宏的功能，尽管了解的并不多，我还是愿意大言不惭的说，python装饰器无论在功能的强大还是丰富性方面都和Lisp的宏很相似。
宏的目标
我觉得，这样对宏进行描述并不过分：一门编程语言中宏的存在是为了提供操作语言元素本身的能力。这恰恰也是python装饰器能做的事情，它们能够对函数进行修改，也能对这个类进行装饰。相比复杂的元类，这也许是大家经常提供一个简单的装饰器的原因吧。
大多数编程语言所提供的能进行自我修改（元编程）的方案都有一个主要的缺点，那就是限制和束缚太多，写着写着有种在写其它语言的错觉。
Python符合Martin Fowler所说的“Enabling”编程语言。所以说，如果你想进行修改操作（元编程），为毛还要弄出一门”不一样“或者”限制多多“的语言呢？为什么不直接抄起python自己咔咔就直接开始干呢？这就是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里面非常有用。
带参数的装饰器
现在我们把上面的那个例子简单的改动一下，看看在添加装饰器参数的情况下会发生什么情况：
class decoratorWithArguments(object):
def __init__(self, arg1, arg2, arg3):
"""
If there are decorator arguments, the function
to be decorated is not passed to the constructor!
"""
print "Inside __init__()"
self.arg1 = arg1
self.arg2 = arg2
self.arg3 = arg3
def __call__(self, f):
"""
If there are decorator arguments, __call__() is only called
once, as part of the decoration process! You can only give
it a single argument, which is the function object.
"""
print "Inside __call__()"
def wrapped_f(*args):
print "Inside wrapped_f()"
print "Decorator arguments:", self.arg1, self.arg2, self.arg3
f(*args)
print "After f(*args)"
return wrapped_f
@decoratorWithArguments("hello", "world", 42)
def sayHello(a1, a2, a3, a4):
print 'sayHello arguments:', a1, a2, a3, a4
print "After decoration"
print "Preparing to call sayHello()"
sayHello("say", "hello", "argument", "list")
print "after first sayHello() call"
sayHello("a", "different", "set of", "arguments")
print "after second sayHello() call"
从输出结果来看，运行的效果发生了明显的变化：
Inside __init__() Inside __call__() After decoration Preparing to call sayHello() Inside wrapped_f() Decorator arguments: hello world 42 sayHello arguments: say hello argument list After f(*args) after first sayHello() call Inside wrapped_f() Decorator arguments: hello world 42 sayHello arguments: a different set of arguments After f(*args) after second sayHello() call
现在，在“装饰”阶段，构造器和__call__()都会被依次调用，__call__()也只接受一个函数对象类型的参数，而且必须返回一个装饰方法去替换原有的方法，__call__()只会在“装饰”阶段被调用一次，接着返回的装饰方法会被实际用在调用过程中。
尽管这个行为很合理，构造器现在被用来捕捉装饰器的参数，而且__call__()不能再被当做装饰方法，相反要利用它来完成装饰的过程。尽管如此，第一次见到这种与不带参数的装饰器迥然不同的行为还是会让人大吃一惊，而且它们的编程范式也有很大的不同。
带参数的函数式装饰器
最后，让我们看一下更复杂的函数式装饰器，在这里你不得不一次完成所有的事情：
def decoratorFunctionWithArguments(arg1, arg2, arg3):
def wrap(f):
print "Inside wrap()"
def wrapped_f(*args):
print "Inside wrapped_f()"
print "Decorator arguments:", arg1, arg2, arg3
f(*args)
print "After f(*args)"
return wrapped_f
return wrap
@decoratorFunctionWithArguments("hello", "world", 42)
def sayHello(a1, a2, a3, a4):
print 'sayHello arguments:', a1, a2, a3, a4
print "After decoration"
print "Preparing to call sayHello()"
sayHello("say", "hello", "argument", "list")
print "after first sayHello() call"
sayHello("a", "different", "set of", "arguments")
print "after second sayHello() call"
输出结果：
Inside wrap() After decoration Preparing to call sayHello() Inside wrapped_f() Decorator arguments: hello world 42 sayHello arguments: say hello argument list After f(*args) after first sayHello() call Inside wrapped_f() Decorator arguments: hello world 42 sayHello arguments: a different set of arguments After f(*args) after second sayHello() call
函数式装饰器的返回值必须是一个函数，能包装原有被包装函数。也就是说，Python会在装饰发生的时候拿到并且调用这个返回的函数结果，然后传递给被装饰的函数，这就是为什么我们在装饰器的实现里嵌套定义了三层的函数，最里层的那个函数是新的替换函数。
因为闭包的特性， wrapped_f()在不需要像在类式装饰器例子中一样显示存储arg1, arg2, arg3这些值的情况下，就能够访问这些参数。不过，这恰巧是我觉得“显式比隐式更好”的例子。尽管函数式装饰器可能更加精简一点，但类式装饰器会更加容易理解并因此更容易被修改和维护。
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]