假以時日，我相信裝飾器一定會成為Python這門編程語言一個更加強大的功能。到目前為止，我覺得到我所看到的有關介紹Python裝飾器的文章都或多或少地會讓人覺得困惑，所以在這兒嘗試看能否修正這些問題。
裝飾器 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里面非常有用。
更多示例
現在你已經基本有了一個概念，你可以在這里找到更多裝飾器的例子，這些例子都是使用的類式裝飾器，不是函數式裝飾器。
在這篇文章中，我故意沒有涉及到帶參數的被裝飾方法，我們下回分解。
[注] “Directing” 和 “Enabling” 是Martin Fowler總結的兩種軟件開發態度，簡單描述下就是：“大部分的開發人員可能比較菜，需要創建約束讓開發人員少犯錯誤，更加規范” vs “讓開發人員自己負責，更加自由，當然自己犯的錯含著淚也要自己搞定”。
原文地址：Decorators I: Introduction to Python Decorators
