（轉(zhuǎn)載）原文地址
在閻宏博士的《JAVA與模式》一書中開頭是這樣描述裝飾（Decorator）模式的：
裝飾模式又名包裝(Wrapper)模式。裝飾模式以對(duì)客戶端透明的方式擴(kuò)展對(duì)象的功能，是繼承關(guān)系的一個(gè)替代方案。
裝飾模式的結(jié)構(gòu)
裝飾模式以對(duì)客戶透明的方式動(dòng)態(tài)地給一個(gè)對(duì)象附加上更多的責(zé)任。換言之，客戶端并不會(huì)覺得對(duì)象在裝飾前和裝飾后有什么不同。裝飾模式可以在不使用創(chuàng)造更多子類的情況下，將對(duì)象的功能加以擴(kuò)展。
裝飾模式的類圖如下：
在裝飾模式中的角色有：
- 抽象構(gòu)件(Component)角色：給出一個(gè)抽象接口，以規(guī)范準(zhǔn)備接收附加責(zé)任的對(duì)象。
- 具體構(gòu)件(ConcreteComponent)角色：定義一個(gè)將要接收附加責(zé)任的類。
- 裝飾(Decorator)角色：持有一個(gè)構(gòu)件(Component)對(duì)象的實(shí)例，并定義一個(gè)與抽象構(gòu)件接口一致的接口。
- 具體裝飾(ConcreteDecorator)角色：負(fù)責(zé)給構(gòu)件對(duì)象“貼上”附加的責(zé)任。
源代碼
抽象構(gòu)件角色
public interface Component {
public void sampleOperation();
}
具體構(gòu)件角色
public class ConcreteComponent implements Component {
@Override
public void sampleOperation() {
// 寫相關(guān)的業(yè)務(wù)代碼
}
}
裝飾角色
public class Decorator implements Component{
private Component component;
public Decorator(Component component){
this.component = component;
}
@Override
public void sampleOperation() {
// 委派給構(gòu)件
component.sampleOperation();
}
}
具體裝飾角色
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關(guān)的業(yè)務(wù)代碼
}
}
public class ConcreteDecoratorB extends Decorator {
public ConcreteDecoratorB(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關(guān)的業(yè)務(wù)代碼
}
}
齊天大圣的例子
孫悟空有七十二般變化，他的每一種變化都給他帶來一種附加的本領(lǐng)。他變成魚兒時(shí)，就可以到水里游泳；他變成鳥兒時(shí)，就可以在天上飛行。
本例中，Component的角色便由鼎鼎大名的齊天大圣扮演；ConcreteComponent的角色屬于大圣的本尊，就是猢猻本人；Decorator的角色由大圣的七十二變扮演。而ConcreteDecorator的角色便是魚兒、鳥兒等七十二般變化。
源代碼
抽象構(gòu)件角色“齊天大圣”接口定義了一個(gè)move()方法，這是所有的具體構(gòu)件類和裝飾類必須實(shí)現(xiàn)的。
//大圣的尊號(hào)
public interface TheGreatestSage {
public void move();
}
具體構(gòu)件角色“大圣本尊”猢猻類
public class Monkey implements TheGreatestSage {
@Override
public void move() {
//代碼
System.out.println("Monkey Move");
}
}
抽象裝飾角色“七十二變”
public class Change implements TheGreatestSage {
private TheGreatestSage sage;
public Change(TheGreatestSage sage){
this.sage = sage;
}
@Override
public void move() {
// 代碼
sage.move();
}
}
具體裝飾角色“魚兒”
public class Fish extends Change {
public Fish(TheGreatestSage sage) {
super(sage);
}
@Override
public void move() {
// 代碼
System.out.println("Fish Move");
}
}
具體裝飾角色“鳥兒”
public class Bird extends Change {
public Bird(TheGreatestSage sage) {
super(sage);
}
@Override
public void move() {
// 代碼
System.out.println("Bird Move");
}
}
客戶端類
public class Client {
public static void main(String[] args) {
TheGreatestSage sage = new Monkey();
// 第一種寫法
TheGreatestSage bird = new Bird(sage);
TheGreatestSage fish = new Fish(bird);
// 第二種寫法
//TheGreatestSage fish = new Fish(new Bird(sage));
fish.move();
}
}
“大圣本尊”是ConcreteComponent類，而“鳥兒”、“魚兒”是裝飾類。要裝飾的是“大圣本尊”，也即“猢猻”實(shí)例。
上面的例子中，系統(tǒng)把大圣從一只猢猻裝飾成了一只鳥兒（把鳥兒的功能加到了猢猻身上），然后又把鳥兒裝飾成了一條魚兒（把魚兒的功能加到了猢猻+鳥兒身上，得到了猢猻+鳥兒+魚兒）。
如上圖所示，大圣的變化首先將鳥兒的功能附加到了猢猻身上，然后又將魚兒的功能附加到猢猻+鳥兒身上。
裝飾模式的簡化
大多數(shù)情況下，裝飾模式的實(shí)現(xiàn)都要比上面給出的示意性例子要簡單。
如果只有一個(gè)ConcreteComponent類，那么可以考慮去掉抽象的Component類（接口），把Decorator作為一個(gè)ConcreteComponent子類。如下圖所示：
如果只有一個(gè)ConcreteDecorator類，那么就沒有必要建立一個(gè)單獨(dú)的Decorator類，而可以把Decorator和ConcreteDecorator的責(zé)任合并成一個(gè)類。甚至在只有兩個(gè)ConcreteDecorator類的情況下，都可以這樣做。如下圖所示：
透明性的要求
裝飾模式對(duì)客戶端的透明性要求程序不要聲明一個(gè)ConcreteComponent類型的變量，而應(yīng)當(dāng)聲明一個(gè)Component類型的變量。
用孫悟空的例子來說，必須永遠(yuǎn)把孫悟空的所有變化都當(dāng)成孫悟空來對(duì)待，而如果把老孫變成的魚兒當(dāng)成魚兒，而不是老孫，那就被老孫騙了，而這時(shí)不應(yīng)當(dāng)發(fā)生的。下面的做法是對(duì)的：
TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);
而下面的做法是不對(duì)的：
Monkey sage = new Monkey();
Bird bird = new Bird(sage);
半透明的裝飾模式
然而，純粹的裝飾模式很難找到。裝飾模式的用意是在不改變接口的前提下，增強(qiáng)所考慮的類的性能。在增強(qiáng)性能的時(shí)候，往往需要建立新的公開的方法。即便是在孫大圣的系統(tǒng)里，也需要新的方法。比如齊天大圣類并沒有飛行的能力，而鳥兒有。這就意味著鳥兒應(yīng)當(dāng)有一個(gè)新的fly()方法。再比如，齊天大圣類并沒有游泳的能力，而魚兒有，這就意味著在魚兒類里應(yīng)當(dāng)有一個(gè)新的swim()方法。
這就導(dǎo)致了大多數(shù)的裝飾模式的實(shí)現(xiàn)都是“半透明”的，而不是完全透明的。換言之，允許裝飾模式改變接口，增加新的方法。這意味著客戶端可以聲明ConcreteDecorator類型的變量，從而可以調(diào)用ConcreteDecorator類中才有的方法：
TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();
半透明的裝飾模式是介于裝飾模式和適配器模式之間的。適配器模式的用意是改變所考慮的類的接口，也可以通過改寫一個(gè)或幾個(gè)方法，或增加新的方法來增強(qiáng)或改變所考慮的類的功能。大多數(shù)的裝飾模式實(shí)際上是半透明的裝飾模式，這樣的裝飾模式也稱做半裝飾、半適配器模式。
裝飾模式的優(yōu)點(diǎn)
裝飾模式與繼承關(guān)系的目的都是要擴(kuò)展對(duì)象的功能，但是裝飾模式可以提供比繼承更多的靈活性。裝飾模式允許系統(tǒng)動(dòng)態(tài)決定“貼上”一個(gè)需要的“裝飾”，或者除掉一個(gè)不需要的“裝飾”。繼承關(guān)系則不同，繼承關(guān)系是靜態(tài)的，它在系統(tǒng)運(yùn)行前就決定了。
通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設(shè)計(jì)師可以創(chuàng)造出很多不同行為的組合。
裝飾模式的缺點(diǎn)
由于使用裝飾模式，可以比使用繼承關(guān)系需要較少數(shù)目的類。使用較少的類，當(dāng)然使設(shè)計(jì)比較易于進(jìn)行。但是，在另一方面，使用裝飾模式會(huì)產(chǎn)生比使用繼承關(guān)系更多的對(duì)象。更多的對(duì)象會(huì)使得查錯(cuò)變得困難，特別是這些對(duì)象看上去都很相像。
設(shè)計(jì)模式在JAVA I/O庫中的應(yīng)用
裝飾模式在Java語言中的最著名的應(yīng)用莫過于Java I/O標(biāo)準(zhǔn)庫的設(shè)計(jì)了。
由于Java I/O庫需要很多性能的各種組合，如果這些性能都是用繼承的方法實(shí)現(xiàn)的，那么每一種組合都需要一個(gè)類，這樣就會(huì)造成大量性能重復(fù)的類出現(xiàn)。而如果采用裝飾模式，那么類的數(shù)目就會(huì)大大減少，性能的重復(fù)也可以減至最少。因此裝飾模式是Java I/O庫的基本模式。
Java I/O庫的對(duì)象結(jié)構(gòu)圖如下，由于Java I/O的對(duì)象眾多，因此只畫出InputStream的部分。
根據(jù)上圖可以看出：
- 抽象構(gòu)件(Component)角色：由InputStream扮演。這是一個(gè)抽象類，為各種子類型提供統(tǒng)一的接口。
- 具體構(gòu)件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實(shí)現(xiàn)了抽象構(gòu)件角色所規(guī)定的接口。
- 抽象裝飾(Decorator)角色：由FilterInputStream扮演。它實(shí)現(xiàn)了InputStream所規(guī)定的接口。
- 具體裝飾(ConcreteDecorator)角色：由幾個(gè)類扮演，分別是BufferedInputStream、DataInputStream以及兩個(gè)不常用到的類LineNumberInputStream、PushbackInputStream。
半透明的裝飾模式
裝飾模式和適配器模式都是“包裝模式(Wrapper Pattern)”，它們都是通過封裝其他對(duì)象達(dá)到設(shè)計(jì)的目的的，但是它們的形態(tài)有很大區(qū)別。
理想的裝飾模式在對(duì)被裝飾對(duì)象進(jìn)行功能增強(qiáng)的同時(shí)，要求具體構(gòu)件角色、裝飾角色的接口與抽象構(gòu)件角色的接口完全一致。而適配器模式則不然，一般而言，適配器模式并不要求對(duì)源對(duì)象的功能進(jìn)行增強(qiáng)，但是會(huì)改變?cè)磳?duì)象的接口，以便和目標(biāo)接口相符合。
裝飾模式有透明和半透明兩種，這兩種的區(qū)別就在于裝飾角色的接口與抽象構(gòu)件角色的接口是否完全一致。透明的裝飾模式也就是理想的裝飾模式，要求具體構(gòu)件角色、裝飾角色的接口與抽象構(gòu)件角色的接口完全一致。相反，如果裝飾角色的接口與抽象構(gòu)件角色接口不一致，也就是說裝飾角色的接口比抽象構(gòu)件角色的接口寬的話，裝飾角色實(shí)際上已經(jīng)成了一個(gè)適配器角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示。
在適配器模式里面，適配器類的接口通常會(huì)與目標(biāo)類的接口重疊，但往往并不完全相同。換言之，適配器類的接口會(huì)比被裝飾的目標(biāo)類接口寬。
顯然，半透明的裝飾模式實(shí)際上就是處于適配器模式與裝飾模式之間的灰色地帶。如果將裝飾模式與適配器模式合并成為一個(gè)“包裝模式”的話，那么半透明的裝飾模式倒可以成為這種合并后的“包裝模式”的代表。
InputStream類型中的裝飾模式
InputStream類型中的裝飾模式是半透明的。為了說明這一點(diǎn)，不妨看一看作裝飾模式的抽象構(gòu)件角色的InputStream的源代碼。這個(gè)抽象類聲明了九個(gè)方法，并給出了其中八個(gè)的實(shí)現(xiàn)，另外一個(gè)是抽象方法，需要由子類實(shí)現(xiàn)。
public abstract class InputStream implements Closeable {
public abstract int read() throws IOException;
public int read(byte b[]) throws IOException {}
public int read(byte b[], int off, int len) throws IOException {}
public long skip(long n) throws IOException {}
public int available() throws IOException {}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {}
public boolean markSupported() {}
}
下面是作為裝飾模式的抽象裝飾角色FilterInputStream類的源代碼。可以看出，F(xiàn)ilterInputStream的接口與InputStream的接口是完全一致的。也就是說，直到這一步，還是與裝飾模式相符合的。
public class FilterInputStream extends InputStream {
protected FilterInputStream(InputStream in) {}
public int read() throws IOException {}
public int read(byte b[]) throws IOException {}
public int read(byte b[], int off, int len) throws IOException {}
public long skip(long n) throws IOException {}
public int available() throws IOException {}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {}
public boolean markSupported() {}
}
下面是具體裝飾角色PushbackInputStream的源代碼。
public class PushbackInputStream extends FilterInputStream {
private void ensureOpen() throws IOException {}
public PushbackInputStream(InputStream in, int size) {}
public PushbackInputStream(InputStream in) {}
public int read() throws IOException {}
public int read(byte[] b, int off, int len) throws IOException {}
public void unread(int b) throws IOException {}
public void unread(byte[] b, int off, int len) throws IOException {}
public void unread(byte[] b) throws IOException {}
public int available() throws IOException {}
public long skip(long n) throws IOException {}
public boolean markSupported() {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {}
public synchronized void close() throws IOException {}
}
查看源碼，你會(huì)發(fā)現(xiàn)，這個(gè)裝飾類提供了額外的方法unread()，這就意味著PushbackInputStream是一個(gè)半透明的裝飾類。換言 之，它破壞了理想的裝飾模式的要求。如果客戶端持有一個(gè)類型為InputStream對(duì)象的引用in的話，那么如果in的真實(shí)類型是 PushbackInputStream的話，只要客戶端不需要使用unread()方法，那么客戶端一般沒有問題。但是如果客戶端必須使用這個(gè)方法，就 必須進(jìn)行向下類型轉(zhuǎn)換。將in的類型轉(zhuǎn)換成為PushbackInputStream之后才可能調(diào)用這個(gè)方法。但是，這個(gè)類型轉(zhuǎn)換意味著客戶端必須知道它 拿到的引用是指向一個(gè)類型為PushbackInputStream的對(duì)象。這就破壞了使用裝飾模式的原始用意。
現(xiàn)實(shí)世界與理論總歸是有一段差距的。純粹的裝飾模式在真實(shí)的系統(tǒng)中很難找到。一般所遇到的，都是這種半透明的裝飾模式。
下面是使用I/O流讀取文件內(nèi)容的簡單操作示例。
public class IOTest {
public static void main(String[] args) throws IOException {
// 流式讀取文件
DataInputStream dis = null;
try{
dis = new DataInputStream(
new BufferedInputStream(
new FileInputStream("test.txt")
)
);
//讀取文件內(nèi)容
byte[] bs = new byte[dis.available()];
dis.read(bs);
String content = new String(bs);
System.out.println(content);
}finally{
dis.close();
}
}
}
觀察上面的代碼，會(huì)發(fā)現(xiàn)最里層是一個(gè)FileInputStream對(duì)象，然后把它傳遞給一個(gè)BufferedInputStream對(duì)象，經(jīng)過BufferedInputStream處理，再把處理后的對(duì)象傳遞給了DataInputStream對(duì)象進(jìn)行處理，這個(gè)過程其實(shí)就是裝飾器的組裝過程，F(xiàn)ileInputStream對(duì)象相當(dāng)于原始的被裝飾的對(duì)象，而BufferedInputStream對(duì)象和DataInputStream對(duì)象則相當(dāng)于裝飾器。
