装饰模式（Decorator）

前言：
装饰模式又名包装模式。装饰模式以对客户端透明以的方式扩展对象的功能，换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下，将对象加以扩展。是继承关系的一个替代方案。
（一）装饰模式的简略图：

（二）装饰模式的环境角色：
1.抽象构件（Component）角色：给出一个抽象接口，以规范准备接受附加责任的对象。
2,具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
3，装饰（Decorator）角色:持有一个构件（Component）对象的实例，并定义一个与抽象接口一致的接口。
4，具体装饰角色（Concrete Decorator）： 负责给构件对象“贴上”附加的责任。
（二）示例源码：
抽象构件（Component）角色:

package com.decorator;
public interface Component
{
    /**
     * 商业方法
     */
    void sampleOperation();
}

装饰（Decorator）角色：

package com.decorator;

public class Decorator implements Component
{
    private Component component;
    /**
     * 构造子
     */
    public Decorator(Component component)
    {
        this.component=component;
    }
    /**
     * 构造子
     */
    public Decorator()
    {
        //write your here;
    }
    /**
     * 商业方法，委派给构件
     */
    public void sampleOperation()
    {
        component.sampleOperation();
    }

}

//虽然它不是一个抽象类，但它的功能是一个抽象角色。
具体构件（Concrete Component）角色：

package com.decorator;

public class ConcreteComponent implements Component
{
    /**
     * 构造子
     */
    public ConcreteComponent()
    {
        //write your code here
    }
    /**
     * 商业方法
     */
    @Override
    public void sampleOperation()
    {
        // TODO Auto-generated method stub

    }

}

具体装饰角色（Concrete Decorator）：

package com.decorator;

public class ConcreteDecorator extends Decorator
{
    /**
     * 商业方法
     */
    public void sampleOperation()
    {
        super.sampleOperation();
    }

}

（三）装饰模式与策略模式的关系
装饰模式将一个东西的表皮换掉，而保持它的内心。策略模式恰好相反，它在保持接口不变的情况下，是具体算法可以互换。
装饰模式的实现要求Component类尽量的“轻”，而策略模式要求抽象策略类尽量的“重”。
（四）何时使用装饰模式：
（1）需要扩展一个类的功能，或给一个类增加附加责任
（2）需要动态地给一个对象增加功能，这些功能可以在动态地撤销。
（3）需要增加一些基本功能的排列组合而产生的非常大量的功能，从而是继承关系变得不现实。
（五）装饰模式的优缺点：
装饰模式的优点:
　　（1）装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”，或者除掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
　　（2）通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合
装饰模式的缺点:
　　由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
　　参考资料：《java与模式》
　　《head first 设计模式》