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

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

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

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

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

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

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

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

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

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

當(dāng)你執(zhí)行這段代碼的時(shí)候，你會(huì)看到這樣的輸出：

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

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

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

因?yàn)橛辛薂這個(gè)裝飾器操作符， 你可以非常優(yōu)雅的得到同樣的結(jié)果：

@staticmethod
def foo(): pass

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

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

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

運(yùn)行結(jié)果是：

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

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

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

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的方法體里面，當(dāng)entryExit被調(diào)用的時(shí)候，new_f()也會(huì)順理成章地被返回。值得注意的是new_f()是一個(gè)閉包，捕獲了參數(shù)變量f的值。
當(dāng)new_f()定義完成后，它將會(huì)被entryExit返回，然后裝飾器機(jī)制發(fā)生作用將結(jié)果賦值成被裝飾的新方法。
代碼print func1.__name__的輸出結(jié)果是new_f，因?yàn)樵谘b飾發(fā)生的過程中，原來的方法已經(jīng)被替換成了new_f，如果對(duì)你來說這是一個(gè)問題的話，你可以在裝飾器返回結(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

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

帶參數(shù)的裝飾器
現(xiàn)在我們把上面的那個(gè)例子簡(jiǎn)單的改動(dòng)一下，看看在添加裝飾器參數(shù)的情況下會(huì)發(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é)果來看，運(yùn)行的效果發(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__()都會(huì)被依次調(diào)用，__call__()也只接受一個(gè)函數(shù)對(duì)象類型的參數(shù)，而且必須返回一個(gè)裝飾方法去替換原有的方法，__call__()只會(huì)在“裝飾”階段被調(diào)用一次，接著返回的裝飾方法會(huì)被實(shí)際用在調(diào)用過程中。
盡管這個(gè)行為很合理，構(gòu)造器現(xiàn)在被用來捕捉裝飾器的參數(shù)，而且__call__()不能再被當(dāng)做裝飾方法，相反要利用它來完成裝飾的過程。盡管如此，第一次見到這種與不帶參數(shù)的裝飾器迥然不同的行為還是會(huì)讓人大吃一驚，而且它們的編程范式也有很大的不同。

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

最新評(píng)論