假以時日，我相信裝飾器一定會成為Python這門編程語言一個更加強大的功能。到目前為止，我覺得到我所看到的有關(guān)介紹Python裝飾器的文章都或多或少地會讓人覺得困惑，所以在這兒嘗試看能否修正這些問題。

裝飾器 vs 裝飾器模式

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

宏的歷史

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

宏的目標(biāo)

我覺得，這樣對宏進行描述并不過分：一門編程語言中宏的存在是為了提供操作語言元素本身的能力。這恰恰也是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"

當(dāng)編譯器走到這段代碼的時候，函數(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()

當(dāng)你執(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)用是兩個非常清晰明了的不同的步驟，這也是我為什么說類似裝飾器更簡單同時也更強大的原因。
當(dāng)函數(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的方法體里面，當(dāng)entryExit被調(diào)用的時候，new_f()也會順理成章地被返回。值得注意的是new_f()是一個閉包，捕獲了參數(shù)變量f的值。
當(dāng)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里面非常有用。

更多示例

現(xiàn)在你已經(jīng)基本有了一個概念，你可以在這里找到更多裝飾器的例子，這些例子都是使用的類式裝飾器，不是函數(shù)式裝飾器。
在這篇文章中，我故意沒有涉及到帶參數(shù)的被裝飾方法，我們下回分解。

下一篇：Python裝飾器Part II：裝飾器參數(shù)

[注] “Directing” 和 “Enabling” 是Martin Fowler總結(jié)的兩種軟件開發(fā)態(tài)度，簡單描述下就是：“大部分的開發(fā)人員可能比較菜，需要創(chuàng)建約束讓開發(fā)人員少犯錯誤，更加規(guī)范” vs “讓開發(fā)人員自己負(fù)責(zé)，更加自由，當(dāng)然自己犯的錯含著淚也要自己搞定”。
原文地址：Decorators I: Introduction to Python Decorators