编程艺术之装饰模式

    当我们需要把所需的功能按正确的顺序串联起来进行控制时，我们就会用到装饰模式。装饰模式就是动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。下面看一下装饰模式的结构图

   

    Component是定义一个对象接口，可以给这些对象动态的添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator，装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。装饰模式是利用SetComponent来对对象进行包装的，这样每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何添加到对象链当中。但是呢，如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。同样道理，如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合成一个类。于是在小菜扮靓第三版中，Component类就被省去了，直接让Decorator继承person类就行了。

     

   装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。在主类中加入了新的字段，新的方法和新的逻辑，从而增加了朱磊的复杂程度。这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行类的特殊行为的需要。而装饰模式却提供了一个非常好的解决方案，它把每个装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，但需要执行特殊行为会死，客户代码就可以在运行时根据需要有选择的、按顺序地使用装饰功能包装对象了。装饰模式的优点是把类中的装饰功能从类中搬移去除，这样可以简化原有中重复的类，有效地把类的核心职责和装饰功能区分开来，而且可以移除相关类中复用的装饰逻辑。但是，装饰模式的装饰顺序很重要，比如加密数据和过滤词汇都可以是数据持久化前的装饰功能，但若先加密了数据再用过滤功能就会出现问题，最理想的情况是保证装饰类之间彼此独立，这样他们就可以以任意的顺序进行组合了。