裝飾器 vs 裝飾器模式
首先，大家需要明白的是使用裝飾器這個詞可能會有不少讓大家擔憂的地方，因為它很容易和設(shè)計模式這本書里面的裝飾器模式發(fā)生混淆。曾經(jīng)一度考慮給這個新的功能取一些其它的術(shù)語名稱，但是裝飾器最終還是勝出了。
的確，你可以使用python裝飾器來實現(xiàn)裝飾器模式，但這絕對是它很小的一部分功能，有點暴殄天物。對于python裝飾器，我覺得它是最接近宏的存在。

宏的歷史
宏有有著非常悠久的歷史，不過大多數(shù)人可能會有使用C語言預(yù)處理宏的經(jīng)驗。但是，對于C語言里的宏來說，它存在一些問題，(1)宏并不存在于C語言中，(2)而且宏的行為有時候會有點詭異，而且經(jīng)常會和C語言的行為不太一致。
為了支持對語言本身的一些元素進行操作，Java和C#都添加了注解。當然他們也都存在一些問題：有時候為了達到自己的目的，你不得不繞過很多的坑。還沒完，這些注解特性還會受到這些語言的一些與生俱來的特性的束手束腳（就像Martin Fowler所描述的 “Directing”）
稍有不同的是，包括我在內(nèi)的很多C++程序員已經(jīng)意識到C++模板的威力，也已經(jīng)在像使用宏一樣在使用這個功能。
很多其他的語言也都包含宏的功能，盡管了解的并不多，我還是愿意大言不慚的說，python裝飾器無論在功能的強大還是豐富性方面都和Lisp的宏很相似。

宏的目標
我覺得，這樣對宏進行描述并不過分：一門編程語言中宏的存在是為了提供操作語言元素本身的能力。這恰恰也是python裝飾器能做的事情，它們能夠?qū)瘮?shù)進行修改，也能對這個類進行裝飾。相比復(fù)雜的元類，這也許是大家經(jīng)常提供一個簡單的裝飾器的原因吧。
大多數(shù)編程語言所提供的能進行自我修改（元編程）的方案都有一個主要的缺點，那就是限制和束縛太多，寫著寫著有種在寫其它語言的錯覺。
Python符合Martin Fowler所說的“Enabling”編程語言。所以說，如果你想進行修改操作（元編程），為毛還要弄出一門”不一樣“或者”限制多多“的語言呢？為什么不直接抄起python自己咔咔就直接開始干呢？這就是python裝飾器能做的。

能用Python裝飾器做些什么
裝飾器能夠讓你“注入”或者”修改“函數(shù)或者類里面的代碼（邏輯）。除了更加簡單和強大之外，裝飾器聽起來有點像AOP面向方面編程的感覺對吧。舉例來說，加入你想在方法的開始或者結(jié)束前做一些事情（比如一些類似于權(quán)限檢查、跟蹤、資源加鎖等一些面向方面編程里的常規(guī)操作）。有了裝飾器，你可以這么做：

@entryExit
def func1():
  print "inside func1()"

@entryExit
def func2():
  print "inside func2()"

函數(shù)的裝飾器
函數(shù)式裝飾器通常會被放在一個函數(shù)定義的代碼前來應(yīng)用合格裝飾器，比如:

@myDecorator
def aFunction():
  print "inside aFunction"

當編譯器走到這段代碼的時候，函數(shù)aFunction會被編譯，編譯得到的函數(shù)對象會傳遞給myDecorator，裝飾器會生成一個新的函數(shù)對象來替換原有的函數(shù)aFunction。
那么，裝飾器myDecorator的代碼實現(xiàn)是怎樣的呢？盡管大多數(shù)的裝飾器入門示例都會寫一個函數(shù)，但是我發(fā)現(xiàn)，相比函數(shù)式裝飾器，類式裝飾器能更好的幫助理解，而且它更加強大。
唯一需要確保的是，裝飾器返回的對象要是像函數(shù)一樣能夠被調(diào)用的，因此類式裝飾器需要實現(xiàn)__call__。
裝飾器應(yīng)該要完成什么工作呢？好吧，它能夠做任何事情，不過通常情況下，你可能會期望原有的被傳遞來的函數(shù)在某個地方能夠被執(zhí)行，盡管這不是強制的：

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()

當你執(zhí)行這段代碼的時候，你會看到這樣的輸出：

inside myDecorator.__init__()
inside aFunction()
Finished decorating aFunction()
inside myDecorator.__call__()

請注意，myDecorator的構(gòu)造器實際是在裝飾函數(shù)的時候執(zhí)行的。我們可以在__init__()里面調(diào)用函數(shù)f，能夠看到，在裝飾器被調(diào)用之前，函數(shù)調(diào)用f()就已經(jīng)完成了。另外，裝飾器的構(gòu)造器能夠接收被裝飾的方法。一般來講，我們會捕捉到這個函數(shù)對象然后接下來在函數(shù)__call__()里面調(diào)用。裝飾和調(diào)用是兩個非常清晰明了的不同的步驟，這也是我為什么說類似裝飾器更簡單同時也更強大的原因。
當函數(shù)aFunction被裝飾完成然后調(diào)用的時候，我們得到了一個完全不同的行為，實際上執(zhí)行的是myDecorator.__call__()的代碼邏輯，這是因為”裝飾“把原有的代碼邏輯用新的返回的邏輯給替換掉了。在我們的例子中，myDecorator對象替換掉了函數(shù)aFunction。事實上，在裝飾器操作符@被加入之前，你不得不做一些比較low的操作來完成同樣的事情：

def foo(): pass
foo = staticmethod(foo)

因為有了@這個裝飾器操作符， 你可以非常優(yōu)雅的得到同樣的結(jié)果：

@staticmethod
def foo(): pass

不過也有不少人因為這一點反對裝飾器，不過@僅僅是一個很小的語法糖而已，把一個函數(shù)對象傳遞給另外一個函數(shù)，然后用返回值替換原有的方法。
我覺著，之所以裝飾器會產(chǎn)生這么大的影響是因為這個小小的語法糖完全改變了人們思考編程的方式。的確，通過將它實現(xiàn)成一個編程語言結(jié)構(gòu)，它將”代碼應(yīng)用到代碼上面“的思想帶到了主流編程思維層面。

青出于藍
現(xiàn)在我們實現(xiàn)一下第一個例子。在這里我們將會做一些很常規(guī)的事情，并且會使用這些代碼：

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()

運行結(jié)果是：

Entering func1
inside func1()
Exited func1
Entering func2
inside func2()
Exited func2

現(xiàn)在我們能夠看到，那些被裝飾的方法有了“進入”和“離開”的跟蹤信息。
構(gòu)造器存儲了通過參數(shù)傳遞進來的函數(shù)對象，在調(diào)用的方法里，我們用函數(shù)對象的__name__屬性來展示被調(diào)用函數(shù)的名稱，然后調(diào)用被裝飾的函數(shù)自己。

使用函數(shù)作為裝飾器
對于裝飾器返回結(jié)果的約束只有一個，那就是能夠被調(diào)用，從而它能夠合理的替換掉原有的被裝飾的那個函數(shù)。在上面的這些例子中，我們是將原有的函數(shù)用包含有__call__()的對象替換的。一個函數(shù)對象同樣能夠被調(diào)用，所以我們可以用函數(shù)來重寫前一個裝飾器的例子，像這樣：

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__

函數(shù)new_f()嵌套定義在entryExit的方法體里面，當entryExit被調(diào)用的時候，new_f()也會順理成章地被返回。值得注意的是new_f()是一個閉包，捕獲了參數(shù)變量f的值。
當new_f()定義完成后，它將會被entryExit返回，然后裝飾器機制發(fā)生作用將結(jié)果賦值成被裝飾的新方法。
代碼print func1.__name__的輸出結(jié)果是new_f，因為在裝飾發(fā)生的過程中，原來的方法已經(jīng)被替換成了new_f，如果對你來說這是一個問題的話，你可以在裝飾器返回結(jié)果之前修改掉函數(shù)的名字：

def entryExit(f):
  def new_f():
    print "Entering", f.__name__
    f()
    print "Exited", f.__name__
  new_f.__name__ = f.__name__
  return new_f

你可以動態(tài)的獲取函數(shù)的信息包括那些你做的更改，這在python里面非常有用。

帶參數(shù)的裝飾器
現(xiàn)在我們把上面的那個例子簡單的改動一下，看看在添加裝飾器參數(shù)的情況下會發(fā)生什么情況：

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"

從輸出結(jié)果來看，運行的效果發(fā)生了明顯的變化：

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

現(xiàn)在，在“裝飾”階段，構(gòu)造器和__call__()都會被依次調(diào)用，__call__()也只接受一個函數(shù)對象類型的參數(shù)，而且必須返回一個裝飾方法去替換原有的方法，__call__()只會在“裝飾”階段被調(diào)用一次，接著返回的裝飾方法會被實際用在調(diào)用過程中。
盡管這個行為很合理，構(gòu)造器現(xiàn)在被用來捕捉裝飾器的參數(shù)，而且__call__()不能再被當做裝飾方法，相反要利用它來完成裝飾的過程。盡管如此，第一次見到這種與不帶參數(shù)的裝飾器迥然不同的行為還是會讓人大吃一驚，而且它們的編程范式也有很大的不同。

帶參數(shù)的函數(shù)式裝飾器
最后，讓我們看一下更復(fù)雜的函數(shù)式裝飾器，在這里你不得不一次完成所有的事情：

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"

輸出結(jié)果：

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

函數(shù)式裝飾器的返回值必須是一個函數(shù)，能包裝原有被包裝函數(shù)。也就是說，Python會在裝飾發(fā)生的時候拿到并且調(diào)用這個返回的函數(shù)結(jié)果，然后傳遞給被裝飾的函數(shù)，這就是為什么我們在裝飾器的實現(xiàn)里嵌套定義了三層的函數(shù)，最里層的那個函數(shù)是新的替換函數(shù)。
因為閉包的特性， wrapped_f()在不需要像在類式裝飾器例子中一樣顯示存儲arg1, arg2, arg3這些值的情況下，就能夠訪問這些參數(shù)。不過，這恰巧是我覺得“顯式比隱式更好”的例子。盡管函數(shù)式裝飾器可能更加精簡一點，但類式裝飾器會更加容易理解并因此更容易被修改和維護。