装饰者模式定义
装饰者模式动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
从定义来看，除了提到比继承更有弹性，其他的还是非常模糊，下面就先给出其UML类图。
从UML类图可以看到装饰者基类（Decorator）主要使用了一个其基类的组合，另外装饰者分别含有自己的新特性，如ConcreteDecoratorA，有自己特有的字段，ConcreteDecoratorB有自己特有的方法。该模式设计的巧妙的地方就在于以上的特点。
为什么说巧妙呢？因为装饰者都含有一个Component的引用，就好比你是老板要找c#开发的，遇到了一个不仅会c#的，还会java的你一样，这样的好处是不容置疑的，不仅可以让你做asp.net，如果哪一天公司要开发andriord了，你照样可以胜任，而不需要再去找andriord的童鞋了，当然也可能是不仅具有C#技能，还可能是能说会道的你。如果哪一天自己想跑业务，自己随时都可以去。跑累了，想体验一下代码生活，照样继续干代码工作……在这个过程中，就像自己被知识武装了起来，所以叫做装饰者模式。
当然有老板要找个什么都会的，全部集中在了一个人身上，也有一定的缺陷，或许一会让你搞andriord，一会让你去搞c#，一会让你跑业务，这样可能会有影响的。敲代码刚刚有思路，就让你去跑业务，显然是有些不科学。
既要武装自己，又要不能老板不时地打扰你的思路，这就需要一个原则：
类应该对扩展开放，对修改关闭。
就是要鼓励学习新东西，但是要禁止打断写代码的思路。这样才能提高效率，那人手不够怎么办，找个新人。
说了这么多，还是觉得通过一个例子才能更好的说明。
装饰者设计模式例子
下面就根据head first设计模式书中的例子，来看看冷饮店是如何卖饮料的。
刚刚开店，只卖矿泉水（MineralWater）和咖啡（Coffee），价钱直接就调用一下其cost()方法就可以的出来。可是聪明的老板一定会想到如果加一下白糖（Sugar）或者牛奶（Milk）是不是可以多赚些呢？但是算账不好算。不可能让矿泉水和咖啡中添加两个方法，AddSugar和AddMilk，这样会产生的问题，如果再加调料，会继续修改饮料的类，这样好不容易写好的类，可能就要继续就改，总共的价格可能也要修改。实在不是好办法。
下面就来看看装饰者模式怎么处理这样的问题。
如果你既是c#程序员，也是andriord程序员，老板说了，我不打断你的思路，白天你可以做C#项目，晚上做andriord的项目，工资的算法你说了算。
你说晚上是白天的2倍，老板说好，财务说，我只看你晚上有没有干，晚上含有白天的引用，计算方法：WageofNight()+Day.wageOfDay()。
同样的道理咖啡店也会通过这样的方式，调料引用一个饮料，总价格通过饮料的价钱加上引用调料的价格。
好了，上图了。咖啡店中饮料类图如下：
感觉不上代码，还是会觉得少些什么，下面就给出对应的代码：
public abstract class Beverage { public string description = "所有饮料的基类"; public abstract double Cost(); public virtual string GetDesciption() { return description; } }