首先說說這個模式產(chǎn)生的背景，需求，或者是一直被<<設(shè)計模式精解>>里提到的場景。
起初的需求是打印一個訂單票據(jù)，然后又要求給加上一個抬頭和一個腳注，再然后又要求抬頭和腳注的數(shù)量不止一個。
其實說一下這個模式在技術(shù)上的一些要點：
先上一段<<設(shè)計模式精解>>里的代碼：
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是繼承或?qū)崿F(xiàn)了核心功能類所繼承或?qū)崿F(xiàn)的父類，這樣通過繼承Decorator，使附加功能和核心功能的接口一致。
2.將Decorator類的構(gòu)造函數(shù)定義成只接受一個類型為Component類參數(shù)的方法，這樣使得附加功能必須找到一個核心功能將其包裝，也就是說附加功能類是不能單獨存在的，必須含有一個核心功能類。
擴(kuò)展：
為Decorator類及其所有子類添加無參構(gòu)造函數(shù)，將Main改寫一下：
class Main {
public static void main(String[] args) {
new Header1(new Footer1()).prtTicket();
}
}
這樣不包裝核心功能可以直接使用附加功能，換句話說，不存在附加功能或核心功能，每個類既可以當(dāng)附加功能也可以當(dāng)核心功能。
最后說一下個人對這個模式的理解：
Decorate，翻譯成中文意思是裝飾，加了個-or就變成裝飾者或者叫裝飾器。既然叫裝飾器，就是要對需要裝飾的東西進(jìn)行包裝，改進(jìn)，使其功能要比原來更多更好，而且既然是裝飾，那就肯定不是主要的，核心的功能，只不過是錦上添花而已，不能喧賓奪主。比如說，原本一臺好好的打印機(jī)，經(jīng)過裝飾后變成了一
臺“可以打印的”洗衣機(jī)，這花添的就大了點，雖說原來的功能還保留著，但是我想這應(yīng)該不是這個模式提出者的初衷。