概 要：在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；
并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”
能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响
降为最低？
定 义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活
优 点：
1、装饰类和被装饰类可以独立发展，而不会相互耦合
2、装饰模型是继承关系的一个替代方案
3、装饰模型可以动态地扩展一个实现类的功能
缺 点：但是要避免多层装饰
使用场景：
1、需要扩展一个类的功能，或给一个类增加附加责任。
2、需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
3、需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式
具体分析：
装饰类感觉与代理类在UML图上有些类似，但是其实质不一样，先来看看UML图：
Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。来看一个例子，小时候考试，回家需要让家长签字，那么这个时候如果成绩考的很差，很定要挨打，那么想个办法对成绩单进行一些扩充，让自己不再挨打呢？如果去直接修改成绩单，那很定是不行的，明眼人都能看出来，而且那个时候制作假证的水平不高，很定会露馅，下面能够解决实际问题的UML的图如下：
