首先说说这个模式产生的背景，需求，或者是一直被<<设计模式精解>>里提到的场景。
起初的需求是打印一个订单票据，然后又要求给加上一个抬头和一个脚注，再然后又要求抬头和脚注的数量不止一个。
其实说一下这个模式在技术上的一些要点：
先上一段<<设计模式精解>>里的代码：
abstract class Component {
public abstract void prtTicket();
}
class SalesTicket extends Component {
public void prtTicket() {
System.out.println("Sales Ticket");
}
}
class Decorator extends Component {
private Component myComp;
public Decorator(Component myC) {
myComp = myC;
}
public void prtTicket() {
if(myComp != null)
myComp.prtTicket();
}
}
class Header1 extends Decorator {
public Header1(Component myC) {
super(myC);
}
public void prtTicket() {
System.out.println("Header 1");
super.prtTicket();
}
}
class Footer1 extends Decorator {
public Footer1(Component myC) {
super(myC);
}
public void prtTicket() {
super.prtTicket();
System.out.println("Footer 1");
}
}
class Main {
public static void main(String[] args) {
new Header1(new Footer1(new SalesTicket())).prtTicket();
}
}
其中，SalesTicket是被包装的对象，也就是核心功能，Decorator是围绕着这个核心功能所要添加的附加功能的抽象类。每个具体的附加功能类都继承Decorator这个类。这样做有两点意义：
1.因为Decorator是继承或实现了核心功能类所继承或实现的父类，这样通过继承Decorator，使附加功能和核心功能的接口一致。
2.将Decorator类的构造函数定义成只接受一个类型为Component类参数的方法，这样使得附加功能必须找到一个核心功能将其包装，也就是说附加功能类是不能单独存在的，必须含有一个核心功能类。
扩展：
为Decorator类及其所有子类添加无参构造函数，将Main改写一下：
class Main {
public static void main(String[] args) {
new Header1(new Footer1()).prtTicket();
}
}
这样不包装核心功能可以直接使用附加功能，换句话说，不存在附加功能或核心功能，每个类既可以当附加功能也可以当核心功能。
最后说一下个人对这个模式的理解：
Decorate，翻译成中文意思是装饰，加了个-or就变成装饰者或者叫装饰器。既然叫装饰器，就是要对需要装饰的东西进行包装，改进，使其功能要比原来更多更好，而且既然是装饰，那就肯定不是主要的，核心的功能，只不过是锦上添花而已，不能喧宾夺主。比如说，原本一台好好的打印机，经过装饰后变成了一
台“可以打印的”洗衣机，这花添的就大了点，虽说原来的功能还保留着，但是我想这应该不是这个模式提出者的初衷。