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