设计模式之装饰（decorator）

装饰模式（decorator pattern）：
    装饰模式又名包装（Wrapper）模式。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。
    装饰模式以对客户端透明的方式动态地给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下，将对象的功能加以扩展。
   
    装饰模式使用原来被装饰的类的一个子类的实例，把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展是完全透明的。
   
    装饰模式中的各个角色：
    抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。
    具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
    （抽象）装饰（Decorator）角色：持有一个构件对象的实例，并定义一个与抽象构件接口一致的接口。接口的实现方法值得注意，每一个实现的方法都委派给父类，但并不单纯地委派，而是有功能的增强。
    by kyo：（抽象）装饰角色应不提供缺省的构造函数，以迫使子类调用其带参的构造函数并传入相应的具体组件对象。
    具体装饰（Concrte Decorator）角色：负责给构件对象 “贴上” 附加的责任。每个具体装饰角色都实现规定的方法，在规定的方法中调用其父类的此方法并添加自己的附加代码。
   
    装饰模式常常被称做包裹模式，就是因为每一个具体装饰类都将下一个具体装饰类或者具体构件类包裹起来。每一层包裹都提供了一些装的功能。(by kyo：怎么感觉和 AOP 的概念有点像...)
   
    在以下情况下应当使用装饰模式：
    1。需要扩展一个类的功能，或给一个类增加附加责任。
    2。需要动态地给一个对象增加功能，这些功能可以再动态的撤销。
    3。需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。
    by kyo：装饰模式应该发尽量使用在无发生次序要求（无状态）的对象中。
   
    使用装饰模式主要有以下优点：
    1。装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
    装饰模式允许系统动态地决定“帖上”一个需要的“装饰”，或者除掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
    2。通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。而继承关系则没有这个优势，每一种不同的排列组合均需要事先通过子类的继承方式设计好。
    3。使用装饰模式，可以比使用继承关系需要较少数目的类。使设计比较易于进行。但另一方面，使用装饰模式会产生比使用继承关系更多的的对象，比较难以控制（装饰模式的动态性较强）。
    使用装饰模式主要的缺点：
    这种比继承方式更加灵活机动的特性，意味着装饰模式比继承更加易于出错。
   
    适配器模式的用意是要改变所考虑的对象的接口而不一定改变对象的性能（特性），而装饰模式的用意是要保持接口，从而增强所考虑对象的性能（特性）。