@aoo def foo(): pass def aoo(fn): return fn
裝飾模式強調動態地給對象添加額外的功能。 Python內置了很多對裝飾器的支持,因此在Python中使用裝飾模式是非常容易的,下面是一個典型的例子,給函數增加日志功能:
import functools def log_wrapper(fun): @functools.wraps(fun) def wrapper(*args, **kwargs): print '在函數執行前加日志' ret = fun(*args, **kwargs) print '在函數執行后家日志' return ret return wrapper @log_wrapper def test(): print 'Hello, 世界'
functools.wraps是Python標準庫提供的一個特殊的裝飾器,用來解決裝飾器帶來的一些常規問題,如函數名稱、doc等的不一致問題。@是Python針對裝飾器提供的一個語法糖,上面的@log_wrapper相當于wrap_test = log_rapper(test),用@后,這個步驟由解釋器代勞了。
裝飾器是Python編程必須掌握的一項技能,在編碼過程中經常會用到。
這里只是一個普通的內嵌函數
def foo(x): y = x def foo1 (): a = 1 return a return foo1
而下面boo則是一個閉包
def aoo(a, b): c = a def boo (x): x = b + 1 return x return boo
boo的特殊性在于引用了外部變量b,當aoo返回后,只要返回值(boo)一直存在,則對b的引用就會一直存在。
上面的知識可能需要花些時間消化,如果你覺得已經掌握了這些知識,下面就回歸正題,看看這些語言特性是怎樣來實現Python中裝飾的概念的。
還是讓我們先看一個簡單的例子,然后逐步深入。這個例子就是加鎖,怎樣實現加鎖的功能?
具體需求是這樣的:我有一個對象,實現了某些功能并提供了一些接口供其它模塊調用,這個對象是運行在并發的環境中的,因此我需要對接口的調用進行同步,第一版的代碼如下:
class Foo(object): def __init__(self, …): self.lock = threading.Lock() def interface1(self, …): self.lock.acquire() try: do something finally: self.lock.release() def interface2(self, …): same as interface1() …
這版代碼的問題很明顯,那就是每個接口函數都有相同的加鎖/解鎖代碼,重復的代碼帶來的是更多的鍵入,更多的閱讀,更多的維護,以及更多的修改,最主要的是,程序員本應集中在業務上的的精力被分散了,而且請注意,真正的業務代碼在距離函數定義2次縮進處開始,即使你的顯示器是寬屏,這也會帶來一些閱讀上的困難。
你直覺的認為,可以把這些代碼收進一個函數中,以達到復用的目的,但是請注意,這些代碼不是一個完整同一的代碼塊,而是在中間嵌入了業務代碼。
現在我們用裝飾器語法來改進這部分代碼,得到第2版代碼:
def sync(func): def wrapper(*args, **kv): self = args[0] self.lock.acquire() try: return func(*args, **kv) finally: self.lock.release() return wrapper class Foo(object): def __init__(self, …): self.lock = threading.Lock() @sync def interface1(self, …): do something @sync def interface2(self, …): do something …
一個裝飾器函數的第一個參數是所要裝飾的那個函數對象,而且裝飾器函數必須返回一個函數對象。如sync函數,當其裝飾interface1時,參數func的值就是interface1,返回值是wrapper,但類Foo實例的interface1被調用時,實際調用的是wrapper函數,在wrapper函數體中間接調用實際的interface1;當interface2被調用時,也調用的是wrapper函數,不過由于在裝飾時func已經變成interface2,所以會間接地調用到實際的interface2函數。
使用裝飾器語法的好處:
代碼量大大的減少了,更少的代碼意味著更少的維護,更少的閱讀,更少的鍵入,好處不一而足(可復用,可維護)
用戶基本上將絕大部分精力放在了業務代碼上,而且少了加減鎖的代碼,可讀性也提高了
缺點:
業務對象Foo中有一個非業務數據成員lock,很礙眼;
相當程度的耦合,wrapper的第一個參數必須是對象本身,而且被裝飾的對象中必須有一個lock對象存在,這給客戶對象添加了限制,使用起來不是很舒服。
我們可以更進一步想一想:
lock對象必須要放在Foo中嗎?
為每個接口函數都鍵入@sync還是很煩人的重復性人工工作,如果漏添加一個,還是會造成莫名其妙的運行時錯誤,為什么不集中處理呢?
為了解決上述的缺點,第3版代碼如下:
class DecorateClass(object): def decorate(self): for name, fn in self.iter(): if not self.filter(name, fn): continue self.operate(name, fn) class LockerDecorator(DecorateClass): def __init__(self, obj, lock = threading.RLock()): self.obj = obj self.lock = lock def iter(self): return [(name, getattr(self.obj, name)) for name in dir(self.obj)] def filter(self, name, fn): if not name.startswith('_') and callable(fn): return True else: return False def operate(self, name, fn): def locker(*args, **kv): self.lock.acquire() try: return fn(*args, **kv) finally: self.lock.release() setattr(self.obj, name, locker) class Foo(object): def __init__(self, …): … LockerDecorator(self).decorate() def interface1(self, …): do something def interface2(self, …): do something …
對對象的功能裝飾是一個更一般的功能,不僅限于為接口加鎖,我用2個類來完成這一功能,DecorateClass是一個基類,只定義了遍歷并應用裝飾功能的算法代碼(template method),LockerDecorator實現了為對象加鎖的功能,其中iter是迭代器,定義了怎樣遍歷對象中的成員(包括數據成員和成員函數),filter是過濾器,定義了符合什么規則的成員才能成為一個接口,operate是執行函數,具體實施了為對象接口加鎖的功能。
而在業務類Foo的__init__函數中,只需要在最后添加一行代碼:LockerDecorator(self).decorate(),就可以完成為對象加鎖的功能。
如果你的對象提供的接口有特殊性,完全可以通過直接改寫filter或者繼承LockerDecorator并覆蓋filter的方式來實現;此外,如果要使用其他的裝飾功能,可以寫一個繼承自DecorateClass的類,并實現iter,filter和operate三個函數即可。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com