分析Python中设计模式之Decorator装饰器模式的要点

先给出一个四人团对Decorator mode的定义:动态地给一个对象添加一些额外的职责。
再来说说这个模式的好处:认证,权限检查,记日志,检查参数,加锁,等等等等,这些功能和系统业务无关,但又是系统所必须的,说的更明白一点,就是面向方面的编程(AOP)。
在Python中Decorator mode可以按照像其它编程语言如C++, Java等的样子来实现,但是Python在应用装饰概念方面的能力上远不止于此,Python提供了一个语法和一个编程特性来加强这方面的功能。Python提供的语法就是装饰器语法(decorator),如下:

@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三个函数即可。

(0)

相关推荐

  • java设计模式之桥接模式(Bridge)

    概述 桥接模式一种结构型模式,它主要应对的是:由于实际的需要,某个类具有两个或以上的维度变化,如果只是用继承将无法实现这种需要,或者使得设计变得相当臃肿. 桥接模式的做法是把变化的部分抽象出来,使变化部分与主类分离开来,从而将多个维度的变化彻底分离.最后,提供一个管理类来组合不同维度上的变化,通过这种组合来满足业务的需要. UML结构图 代码示例 package interview; interface Implementor{ void operationImpl(); } abstract

  • java设计模式之组合模式(Composite)

    概述 是一种结构型模式,将对象以树形结构组织起来,以表示"部分 - 整体"的层次结构,使得客户端对单个对象和组合对象的使用具有唯一性. UML类图 上面的类图包含的角色: Component:为参加组合的对象声明一个公共的接口,不管是组合还是叶节点. Leaf:在组合中表示叶子结点对象,叶子结点没有子结点. Composite:表示参加组合的有子对象的对象,并给出树枝构建的行为: 代码示例 import java.util.ArrayList; import java.util.Lis

  • C#装饰器模式(Decorator Pattern)实例教程

    本文以实例形式详细讲述了C#装饰器模式的实现方法.分享给大家供大家参考.具体实现方法如下: 现假设有一个公司要做产品套餐,即把不同的产品组合在一起,不同的组合对应不同的价格.最终呈现出来的效果是:把产品组合的所有元素呈现出来,并显示该组合的价格. 每个产品都有名称和价格,首先设计一个关于产品的抽象基类. public abstract class ProductBase { public abstract string GetName(); public abstract double GetP

  • 学习php设计模式 php实现装饰器模式(decorator)

    动态的给一个对象添加一些额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活[GOF95] 装饰模式是以对客户透明的方式动态地给一个对象附加上更多的职责.这也就是说,客户端并不会觉得对象在装饰前和装饰后有什么不同.装饰模式可以在不使用创造更多子类的情况下,将对象的功能加以扩展. 一.装饰模式结构图 二.装饰模式中主要角色 抽象构件(Component)角色:定义一个对象接口,以规范准备接收附加职责的对象,从而可以给这些对象动态地添加职责. 具体构件(Concrete Compo

  • PHP、Python和Javascript的装饰器模式对比

    修饰模式(Decorator Pattern),又叫装饰者模式,是面向对象编程领域中,一种动态地往一个类中添加新的行为的设计模式.就功能而言,修饰模式相比生成子类更为灵活,这样可以给某个对象而不是整个类添加一些功能.装饰模式非常适用于灵活扩展对象的功能,下面是装饰模式的UML图: 例如,有一个技术论坛,用户通过留言进行沟通,由于刚开始论坛里都是熟人,几乎都不需要对留言的内容作出审核,接收留言的页面可以是这样: class SaveMsg(){ private $msg; public funct

  • java设计模式之观察者模式

    观察者模式又称发布-订阅(Publish/Subscribe)模式,定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象.这个主题对象在状态发生变化时,会通知所有观察者对象,使他们能够自动更新自己.将一个系统分割成一系列相互协作的类有一个很不好的副作用,那就是需要维护相关对象间的一致性.我们不希望为了维持一致性而使各类紧密耦合,这样会给维护.扩展和复用都带来不便.观察者模式所做的工作其实就是在解除耦合,让耦合的双方都依赖于抽象,而不是依赖于具体. 观察者模式是实际中应用比较广泛的模

  • Python的装饰器模式与面向切面编程详解

    今天来讨论一下装饰器.装饰器是一个很著名的设计模式,经常被用于有切面需求的场景,较为经典的有插入日志.性能测试.事务处理等.装饰器是解决这类问题的绝佳设计,有了装饰器,我们就可以抽离出大量函数中与函数功能本身无关的雷同代码并继续重用.概括的讲,装饰器的作用就是为已经存在的对象添加额外的功能. 1. 装饰器入门 1.1. 需求是怎么来的? 装饰器的定义很是抽象,我们来看一个小例子. 复制代码 代码如下: def foo():     print 'in foo()'   foo() 这是一个很无聊

  • 深入解析设计模式中的装饰器模式在iOS应用开发中的实现

    装饰器模式可以在不修改代码的情况下灵活的为一对象添加行为和职责.当你要修改一个被其它类包含的类的行为时,它可以代替子类化方法. 一.基本实现 下面我把类的结构图向大家展示如下: 让我们简单分析一下上面的结构图,Component是定义一个对象接口,可以给这些对象动态地添加职责.ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责.Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需

  • 实例讲解Ruby使用设计模式中的装饰器模式的方法

    概述        若你从事过面向对象开发,实现给一个类或对象增加行为,使用继承机制,这是所有面向对象语言的一  个基本特性.如果已经存在的一个类缺少某些方法,或者须要给方法添加更多的功能(魅力),你也许会仅仅继承这个类来产生一个新类-这建立在额外的代码上.       通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法.但是这种方法是静态的,用户不能控制增加行为的方式和时机.如果  你希望改变一个已经初始化的对象的行为,你怎么办?或者,你希望继承许多类的行为,改怎么办?前一个,

  • java设计模式之装饰器模式(Decorator)

    概述 装饰模式是对客户端以透明的方式扩展对象的功能,是继承关系的一个替代方案.也就是说,客户端并不会觉得对象在装饰前和装饰后有什么不同,装饰模式可以在不用创造更多子类的情况下,将对象的功能加以扩展,装饰模式的关键在于这种扩展是完全透明的. 模式的结构 UML类图: 装饰模式中的类角色: 抽象构件角色(Project):给出一个接口,以规范准备接收附加责任的对象 具体构件角色(Employe):定义一个将要接收附加责任的类 装饰角色(Manager):持有一个构件对象的实例,并定义一个与抽象构件接

随机推荐