JAVA23种设计模式之一，英文叫Decorator Pattern，又叫装饰者模式。装饰模式是在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能.
1、装饰模式与类继承的区别：
1) 装饰模式是一种动态行为，对已经存在类进行随意组合，而类的继承是一种静态的行为，一个类定义成什么样的，该类的对象便具有什么样的功能，无法动态的改变。
所谓动态是说可以在系统运行时(RunTime)动态给对象增加其它职责而不需要修改代码或重新编译；所谓静态是说必须通过调整代码(DesignTime)才能给对象增加职责,而且系统还需要重新编译；从具体技术层面来说，对象的组合和继承正好对应于前面的动态和静态，因为通过对象组合建立的交互关系不是在代码中(DesignTime)固定死的，而是在运行时(RunTime)动态组合的；而通过继承建立的关系是僵硬的难以改变的，因为它是在代码中(DesignTime)固定死了的，根本不存在运行时(RunTime)改变的可能。换个角度说：我们应该多使用对象组合来保持系统的运行时扩展性，尽量少使继承。
2) 装饰模式扩展的是对象的功能，不需要增加类的数量，而类继承扩展是类的功能，在继承的关系中，如果我们想增加一个对象的功能，我们只能通过继承关系，在子类中增加两个方法
2、 装饰模式的特点：
1) 装饰对象和真实对象具有相同的接口，这样客户端对象就可以以真实对象的相同的方式和装饰对象交互。
2) 装饰对象包含一个真实对象的引用(reference).
3) 装饰对象接受所有来自客户端的请求，它把这些请求转发给真实的对象。
4) 装饰对象可以在转发这些请求以前或者以后增加一些附加的功能。这样就能确保在运行时，不用修改给定对象结构就可以在外部增加附加的功能。在面向对象的程序设计中，通常是使用继承的关系来扩展给定类的功能
3、装饰模式的实现：
Component：
定义一个对象接口，可以给这些对象动态地添加职责。
public interface Component{ void operation();} Concrete Component：
定义一个对象，可以给这个对象添加一些职责。
public class ConcreteComponent implements Component{ public void operation() { // Write your code here }} Decorator：
维持一个指向Component对象的引用，并定义一个与 Component接口一致的接口。
public class Decorator implements Component{ public Decorator(Component component) { this.component = component; } public void operation() { component.operation(); } private Component component;} Concrete Decorator：
在Concrete Component的行为之前或之后，加上自己的行为，以“贴上”附加的职责。
public class ConcreteDecorator extends Decorator{ public void operation() { //addBehavior也可以在前面 super.operation(); addBehavior(); } private void addBehavior() { //your code }} public class Client 1. 如果只有一个Concrete Component类而没有抽象的Component接口时，可以让Decorator继承Concrete Component。
2. 如果只有一个Concrete Decorator类时，可以将Decorator和Concrete Decorator合并。
Decorator是装饰者模式里非常特殊的一个类，它既继承于Component【IS A关系】,又维护一个指向Component实例的引用【HAS A关系】，换个角度来说，Decorator跟Component之间，既有动态组合关系又有静态继承关系，WHY? 这里为什么要这么来设计？上面我们说过，组合的好处是可以在运行时给对象增加职责，Decorator【HAS A】Component的目的是让ConcreteDecorator可以在运行时动态给ConcreteComponent增加职责，这一点相对来说还比较好理解；那么Decorator继承于Component的目的是什么？在这里，继承的目的只有一个，那就是可以统一装饰者和被装饰者的接口，换个角度来说，不管是ConcretComponent还是ConcreteDecorator，它们都是 Component，用户代码可以把它们统一看作Component来处理，这样带来的更深一层的好处就是，装饰者对象对被装饰者对象的功能职责扩展对用户代码来说是完全透明的，因为用户代码引用的都是Component，所以就不会因为被装饰者对象在被装饰后，引用它的用户代码发生错误，实际上不会有任何影响，因为装饰前后，用户代码引用的都是Component类型的对象，这真是太完美了！装饰者模式通过继承实现统一了装饰者和被装饰者的接口，通过组合获得了在运行时动态扩展被装饰者对象的能力。
给一个对象动态添加额外职责，这些职责需要由用户决定加入的方式和时机。装饰模式提供了“即插即用”的方式，在运行期间决定何时增加何种功能。就增加功能来说，装饰模式比生成子类更加灵活。