python中的装饰器decorator

装饰器的语法以@开头，接着是装饰器要装饰的函数的申明等。

其实总体说起来，装饰器其实也就是一个函数，一个用来包装函数的函数，装饰器在函数申明完成的时候被调用，调用之后申明的函数被换成一个被装饰器装饰过后的函数。

装饰器分为无参装饰和有参装饰

def deco(func):
    def replaceFunc():     #定义一个内嵌函数，此函数包装了被装饰的函数，并提供额外操作的代码
        print "Enter decorator"     #进行额外操作
        return func()    #产生对被装饰函数的调用
    return replaceFunc   #由于返回的是这个新的内嵌函数，所以确保额外操作每次调用得以运行

@deco
def MyFunc():   #应用@deco修饰的方法
    print "Enter MyFunc"

MyFunc()     #调用被装饰的函数

输出结果:
 Enter decorator
 Enter MyFunc

 
效果等同于: deco(MyFunc)  见replaceFunc-->先print然后调用被装饰函数.

每个decorator只是一个方法， 可以是自定义的或者内置的（如内置的@staticmethod/@classmethod）。decorator方法把要装饰的方法作为输入参数，在函数体内可以进行任意的操作(可以想象其中蕴含的威力强大，会有很多应用场景)，只要确保最后返回一个可执行的函数即可（可以是原来的输入参数函数，或者是一个新函数）。

decorator对于剥离验证和错误处理等常用逻辑很有用处,  类似于c/c++中用宏来定义一些结构上类似的函数.

设计模式之Decorator:
 意图
　　 动态地给一个对象添加一些额外的职责(动态包装)。就增加功能来说，Decorator模式相比生成子类更为灵活。
 在以下情况下应当使用装饰模式：
  需要扩展一个类的功能，或给一个类增加附加责任。
  需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
  需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

使用装饰模式主要有以下的优点：

装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错。
Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。

 

使用装饰模式主要有以下的缺点：

由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

 

继承带来的可能问题:
一来继承的层次可能会很多，二来子类的数量可能会很多。

 

Ref link:
http://lijiong-say.spaces.live.com/Blog/cns!D9877CF89E4689B1!129.entry
http://blog.youkuaiyun.com/suiyunonghen/archive/2009/03/06/3962885.aspx
[GAE自动管理memcache的装饰器]http://www.119797.com/program/gae-memcache/
[如何利用Python的decorator彻底的分离软件中的横切面]http://www.yuntien.com/forum/post/10835/
[无废话C#设计模式之十三：Decorator]http://dev.yesky.com/173/7686173.shtml
http://terrylee.cnblogs.com/archive/2006/03/01/340592.html
http://www.cnblogs.com/zhenyulu/articles/46735.html