装饰者模式（Decorator）

首先来看一个例子：
      比如，饮料可以分为很多种类，而这里我取一个咖啡，那么这个咖啡呢，有多种形式的，比如有加糖了的咖啡，有加奶的咖啡，也有加热了的咖啡，也有加了冰块的咖啡。
      而各个顾客的选择却是不同的，比如，有的客户是要加糖的咖啡，而有的客户却是要加冰的咖啡，也就是需求是各种各样的，那么如何实现这种情况呢？

先来看一种愚笨的做法，那就是你可以通过继承来实现：

      虽然上面的做法确实可以提供加糖加冰的咖啡，但是，这种方法也太拙劣了吧，如果我要加糖和加热的咖啡呢？如果我还有更多的需求呢？如果我新增饮料巧克力奶茶，然后其中也可以加糖，加奶，加热，加冰呢？如果使用上面的方式来完成上面提到的种种需求的话？My God ！！！
      其实从上面的例子中反映出来的问题是，确实可以通过继承来实现扩展（比如，由咖啡扩展成了加了糖的咖啡），但是并不一定说使用继承就可以达到弹性设计。为了解决上面出现的问题，一种新的设计模式应运而生，那就是装饰者模式。

      装饰者模式动态的给一个对象添加一些责任（也就是功能），若要扩展功能的话，装饰者提供了比继承更有弹性的替代方案，因为装饰者模式比生成子类更加灵活。首先来看一下装饰者模式的结构图：

      下面就来解释装饰者模式了
      装饰者模式呢，其实可以看做是一种在已有功能上动态添加新的功能的一种方式，在不用装饰者模式的前提下，如果要在已有的功能上添加新功能，一般都是可以使用继承的，但是，继承的缺点呢，在上面的咖啡的例子中也暴露的很明显，同时，使用继承的话，添加功能不是动态的，因为子类完全继承了父类，而使用装饰者模式的话，您可以在客户端按照需求一个一个的包装对象，通过包装对象来添加新功能，这样便实现了动态添加新功能。
      比如，我可以对 Component 通过 ConcreteDecoratorA 来包装一个 State 状态，或者是通过 ConcreteDecoratorB 来包装一个新的行为（功能）Behavior ，这样便实现了功能的动态添加。又比如上面的咖啡的例子，就可以使用装饰者模式来实现，我先是对咖啡使用加糖来包装，这样就可以得到加糖的咖啡，而后再使用冰来包装加了糖的咖啡，这样就可以得到加了糖，并且加了冰的咖啡。
      其实光这样说是感受不到多少装饰者模式带来的优点的，下面就将上面提到的咖啡这个例子写出来看看吧，这样理解起来便清晰多了。

    Drink 类

public abstract class Drink {//定义抽象接口，动态的给对象添加功能public abstract void showDrink();}

    Coffee 类

public class Coffee extends Drink{private String name;public Coffee(String name){this.name = name;}//给当前对象添加一些功能，这里打印咖啡的名称@Overridepublic void showDrink() {System.out.println("咖啡名称:"+this.name);}}

    DecoratorDrink 类

public class DecorateDrink extends Drink{//装饰类中有对象的一个引用private Drink drink;public DecorateDrink(Drink drink){this.drink = drink;}//必须执行父类的方法@Overridepublic void showDrink() {drink.showDrink();}}

    装饰类 Sugar

public class Sugar extends DecorateDrink{//有要扩展的对象，调用父类的构造函数public Sugar(Drink drink) {super(drink);}@Overridepublic void showDrink() {//调用父类的showDrink函数super.showDrink();//之后添加自己的新功能System.out.println("添加口味:加糖");}}

    装饰类 Milk

public class Milk extends DecorateDrink{public Milk(Drink drink) {super(drink);}@Overridepublic void showDrink() {super.showDrink();//添加新功能System.out.println("添加口味:加奶");}}

    Main 函数

public class Test {public static void main(String[] args){//new一个咖啡对象，是后边用于装饰的对象Coffee coffee = new Coffee("奶糖咖啡");//用糖来装饰咖啡Sugar sugar = new Sugar(coffee);//用奶来装饰加了糖的咖啡Milk milk = new Milk(sugar);//显示目前咖啡的状态milk.showDrink();}}

      最后是运行结果：

      从 Main 函数中可以看出，我可以方便的通过将各个装饰类组合起来（一个个的新功能添加起来）而成为新产品，上面呢，就是装饰者模式的一个最基本的应用和介绍了。
      其实，装饰者模式呢，它把类中的一些装饰功能移除，再将这些装饰功能写到另外的类中，这样可以简化核心类的复杂度，同时，面对不同的需求时，可以提供代码得复用，否则，你要完成需求“咖啡加糖”的话，就得写一个咖啡加糖类，再变点需求又得变一大堆，通过装饰模式，可以有效的将类的核心功能和装饰功能分离开来，比如上面的 Demo 的核心功能是咖啡，而装饰功能就是加糖，加奶，加热，加冰这些了，同时，通过装饰者模式，你可以很好的扩展自己的设计，比如，上面的 Demo ，如果在后面再来需求，说可以加盐（应该不会有这种需求吧？哈哈哈），那么你只需再完成一个加盐的装饰类，然后再在客户端动态添加加盐这项新功能就可以了，而上面提到的这些，用继承几乎上无法避免违背开闭原则。

     同时，在这里还必须提一下的就是，装饰模式的装饰顺序很重要，在上面的 Demo 中无法体现出装饰模式装饰顺序的重要性，再来看一个装饰的例子，以用来体现出装饰模式装饰顺序的重要，那就是一个人，它穿衣服，其实是可以用装饰模式来解决的，因为你可以把内衣，外衣，内裤，外裤，鞋子等等内容都看做一个个的装饰类，那么这里，装饰顺序就显得比较重要了，比如，如果你先装饰了外裤，然后再装饰内裤，那就麻烦大了，因为你变成了超人---典型的内裤外穿~~~~~从这里可以看出装饰顺序还是很重要的！！！
      上面提到的都是装饰模式的优点，而事实上，任何事物都是两面的，有利必有弊，装饰模式也一样的，那就是使用装饰模式，会使整个的设计当中出现很多的小类，也就是许许多多的装饰类，比如，上面的关于咖啡的 Demo 中就出现了 4 个小的装饰类，如果，一个设计中，装饰模式过度使用的话，会平添很多的小类，那样的话，会让程序变得更加复杂。
      关于装饰模式呢，就谈到这里了~~~

（转自：http://blog.163.com/michael_yu/blog/static/173853371201010365749187/）