装饰模式能动态地给一个对象添加一些额外的职责。即不改变或者继承一个类，而是使用装饰类来对一个对象进行修饰以后，返回该修饰之后的对象。在有些情况下，需要给某个对象而不是整个类添加一些功能。例如，一个图形用户界面工具箱的类提供对任意一个用户界面组件添加一些特性的接口（例如边框，或是一些行为，例如窗口滚动）使用继承机制是添加功能的一种有效途径，从其他类继承过来的边框特性可以被多个子类的实例所使用。但这种方法不够灵活，因为边框的选择是静态的，用户不能控制对组件加边框的方式和时机。一种较为灵活的方式是将组件嵌入另一个对象中，由这个对象添加边框。我们称这个嵌入的对象为装饰。这个装饰与它所装饰的组件接口一致，因此它对使用该组件的客户透明。它将客户请求转发给该组件，并且可能在转发前后执行一些额外的动作（例如画一个边框）。透明性使得设计者可以递归的嵌套多个装饰，从而可以添加任意多的功能。

装饰模式的类图见图。Component定义一个对象接口，可以给这些对象动态地添加职责；ConcreteComponent定义一个对象，可以给这个对象添加一些职责；Decorator维持一个指向Component对象的指针，并定义一个与Component接口一致的接口；ConcreteDecorator向组件添加职责。

装饰模式的类图

装饰模式的使用情形有：①在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。②在处理那些可以撤销的职责的情况下。③当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

装饰模式至少有两个主要优点和两个缺点：①比静态继承更灵活。与对象的静态继承（多重继承）相比，装饰模式提供了更加灵活的向对象添加职责的方式。可以用添加和分离的方法，用装饰在运行时刻增加和删除职责。相比之下，继承机制要求为每个添加的职责创建一个新的子类。这会产生许多新的类，并且会增加系统的复杂度。此外，为一个特定的Component类提供多个不同的Decorator类，即支持对一些职责进行混合和匹配。使用装饰模式可以很容易地重复添加一个特性，例如在TextView上添加双边框时，仅需将添加两个BorderDecorator即可。而两次继承Border类则极容易出错的。②避免在层次结构高层的类有太多的特征装饰模式提供了一种“即用即付”的方法来添加职责。它并不试图在一个复杂的可定制的类中支持所有可预见的特征，相反，用过定义一个简单的类，接着用Decorator类给它逐渐地添加功能。可以从简单的部件组合出复杂的功能。这样，应用程序不必为不需要的特征付出代价。同时也更易于不依赖于Decorator所扩展（甚至是不可预知的扩展）的类而独立地定义新类型的Decorator。扩展一个复杂类的时候，很可能会暴露与添加的职责无关的细节。③Decorator与它的Component不一样，Decorator是一个透明的包装。如果我们从对象标识的观点出发，一个被装饰了的组件与这个组件是有差别的，因此，使用装饰时不应该依赖对象标识。④有许多小对象采用装饰模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同，而不是它们的类或是它们的属性值有所不同。尽管对于那些了解这些系统的人来说，很容易对它们进行定制，但是很难学习这些系统，排错也很困难。