一、基本概念
裝飾模式又名包裝(Wrapper)模式，裝飾模式以對客戶端透明的方式擴展物件的功能，是繼承關系的一個替代方案，
二、通俗解釋
DECORATOR裝飾模式：Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面寫上“最好的的禮物，就是愛你的Fita”，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，我們都是Decorator，最終都在修飾我這個人呀，怎么樣，看懂了嗎？ 裝飾模式：裝飾模式以對客戶端透明的方式擴展物件的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性，動態給一個物件增加功能，這些功能可以再動態的撤消，增加由一些基本功能的排列組合而產生的非常大量的功能，
三、分類
我把裝飾模式分為兩類：純粹裝飾模式和簡化裝飾模式，咱們實際應用中其實后者用的比較多，為了弄清楚裝飾模式的含義，我們先看純粹模式，
1.純粹裝飾模式的結構
裝飾模式以對客戶透明的方式動態地給一個物件附加上更多的責任，換言之，客戶端并不會覺得物件在裝飾前和裝飾后有什么不同，裝飾模式可以在不使用創造更多子類的情況下，將物件的功能加以擴展，
裝飾模式的類圖如下：
在裝飾模式中的角色有：
● 抽象構件(Component)角色：給出一個抽象介面，以規范準備接收附加責任的物件，
● 具體構件(ConcreteComponent)角色：定義一個將要接收附加責任的類，
● 裝飾(Decorator)角色：持有一個構件(Component)物件的實體，并定義一個與抽象構件介面一致的介面，
● 具體裝飾(ConcreteDecorator)角色：負責給構件物件“貼上”附加的責任，
抽象構件角色
public interface Component {
public void sampleOperation();
}具體構件角色
public class ConcreteComponent implements Component {
@Override
public void sampleOperation() {
// 寫相關的業務代碼
}
}裝飾角色
public class Decorator implements Component{
private Component component;
public Decorator(Component component){
this.component = component;
}
@Override
public void sampleOperation() {
// 委派給構件
component.sampleOperation();
}
}具體裝飾角色
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關的業務代碼
}
}public class ConcreteDecoratorB extends Decorator {
public ConcreteDecoratorB(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關的業務代碼
}
}齊天大圣的例子
孫悟空有七十二般變化，他的每一種變化都給他帶來一種附加的本領，他變成魚兒時，就可以到水里游泳；他變成鳥兒時，就可以在天上飛行，
本例中，Component的角色便由鼎鼎大名的齊天大圣扮演；ConcreteComponent的角色屬于大圣的本尊，就是猢猻本人；Decorator的角色由大圣的七十二變扮演，而ConcreteDecorator的角色便是魚兒、鳥兒等七十二般變化，
抽象構件角色“齊天大圣”介面定義了一個move()方法，這是所有的具體構件類和裝飾類必須實作的，
//大圣的尊號
public interface TheGreatestSage {
public void move();
}具體構件角色“大圣本尊”猢猻類
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類，而“鳥兒”、“魚兒”是裝飾類，要裝飾的是“大圣本尊”，也即“猢猻”實體，
上面的例子中，系統把大圣從一只猢猻裝飾成了一只鳥兒（把鳥兒的功能加到了猢猻身上），然后又把鳥兒裝飾成了一條魚兒（把魚兒的功能加到了猢猻+鳥兒身上，得到了猢猻+鳥兒+魚兒），
如上圖所示，大圣的變化首先將鳥兒的功能附加到了猢猻身上，然后又將魚兒的功能附加到猢猻+鳥兒身上，
2.簡化裝飾模式的結構
大多數情況下，裝飾模式的實作都要比上面給出的示意性例子要簡單，
如果只有一個ConcreteComponent類，那么可以考慮去掉抽象的Component類（介面），把Decorator作為一個ConcreteComponent子類，如下圖所示：
如果只有一個ConcreteDecorator類，那么就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合并成一個類，甚至在只有兩個ConcreteDecorator類的情況下，都可以這樣做，如下圖所示：
透明性的要求
裝飾模式對客戶端的透明性要求程式不要宣告一個ConcreteComponent型別的變數，而應當宣告一個Component型別的變數，
用孫悟空的例子來說，必須永遠把孫悟空的所有變化都當成孫悟空來對待，而如果把老孫變成的魚兒當成魚兒，而不是老孫，那就被老孫騙了，而這時不應當發生的，下面的做法是對的：
TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);而下面的做法是不對的：
Monkey sage = new Monkey();
Bird bird = new Bird(sage);半透明的裝飾模式
然而，純粹的裝飾模式很難找到，裝飾模式的用意是在不改變介面的前提下，增強所考慮的類的性能，在增強性能的時候，往往需要建立新的公開的方法，即便是在孫大圣的系統里，也需要新的方法，比如齊天大圣類并沒有飛行的能力，而鳥兒有，這就意味著鳥兒應當有一個新的fly()方法，再比如，齊天大圣類并沒有游泳的能力，而魚兒有，這就意味著在魚兒類里應當有一個新的swim()方法，
這就導致了大多數的裝飾模式的實作都是“半透明”的，而不是完全透明的，換言之，允許裝飾模式改變介面，增加新的方法，這意味著客戶端可以宣告ConcreteDecorator型別的變數，從而可以呼叫ConcreteDecorator類中才有的方法：
TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();半透明的裝飾模式是介于裝飾模式和配接器模式之間的，配接器模式的用意是改變所考慮的類的介面，也可以通過改寫一個或幾個方法，或增加新的方法來增強或改變所考慮的類的功能，大多數的裝飾模式實際上是半透明的裝飾模式，這樣的裝飾模式也稱做半裝飾、半配接器模式，
裝飾模式的優點
（1）裝飾模式與繼承關系的目的都是要擴展物件的功能，但是裝飾模式可以提供比繼承更多的靈活性，裝飾模式允許系統動態決定“貼上”一個需要的“裝飾”，或者除掉一個不需要的“裝飾”，繼承關系則不同，繼承關系是靜態的，它在系統運行前就決定了，
（2）通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合，
裝飾模式的缺點
由于使用裝飾模式，可以比使用繼承關系需要較少數目的類，使用較少的類，當然使設計比較易于進行，但是，在另一方面，使用裝飾模式會產生比使用繼承關系更多的物件，更多的物件會使得查錯變得困難，特別是這些物件看上去都很相像，
四、設計模式在JAVA I/O庫中的應用
裝飾模式在Java語言中的最著名的應用莫過于Java I/O標準庫的設計了，
由于Java I/O庫需要很多性能的各種組合，如果這些性能都是用繼承的方法實作的，那么每一種組合都需要一個類，這樣就會造成大量性能重復的類出現，而如果采用裝飾模式，那么類的數目就會大大減少，性能的重復也可以減至最少，因此裝飾模式是Java I/O庫的基本模式，
Java I/O庫的物件結構圖如下，由于Java I/O的物件眾多，因此只畫出InputStream的部分，
根據上圖可以看出：
● 抽象構件(Component)角色：由InputStream扮演，這是一個抽象類，為各種子型別提供統一的介面，
● 具體構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演，它們實作了抽象構件角色所規定的介面，
● 抽象裝飾(Decorator)角色：由FilterInputStream扮演，它實作了InputStream所規定的介面，
● 具體裝飾(ConcreteDecorator)角色：由幾個類扮演，分別是BufferedInputStream、DataInputStream以及兩個不常用到的類LineNumberInputStream、PushbackInputStream，
半透明的裝飾模式
裝飾模式和配接器模式都是“包裝模式(Wrapper Pattern)”，它們都是通過封裝其他物件達到設計的目的的，但是它們的形態有很大區別，
理想的裝飾模式在對被裝飾物件進行功能增強的同時，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致，而配接器模式則不然，一般而言，配接器模式并不要求對源物件的功能進行增強，但是會改變源物件的介面，以便和目標介面相符合，
裝飾模式有透明和半透明兩種，這兩種的區別就在于裝飾角色的介面與抽象構件角色的介面是否完全一致，透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致，相反，如果裝飾角色的介面與抽象構件角色介面不一致，也就是說裝飾角色的介面比抽象構件角色的介面寬的話，裝飾角色實際上已經成了一個配接器角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示，
在配接器模式里面，配接器類的介面通常會與目標類的介面重疊，但往往并不完全相同，換言之，配接器類的介面會比被裝飾的目標類介面寬，
顯然，半透明的裝飾模式實際上就是處于配接器模式與裝飾模式之間的灰色地帶，如果將裝飾模式與配接器模式合并成為一個“包裝模式”的話，那么半透明的裝飾模式倒可以成為這種合并后的“包裝模式”的代表，
InputStream型別中的裝飾模式
InputStream型別中的裝飾模式是半透明的，為了說明這一點，不妨看一看作裝飾模式的抽象構件角色的InputStream的源代碼，這個抽象類宣告了九個方法，并給出了其中八個的實作，另外一個是抽象方法，需要由子類實作，
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類的源代碼，可以看出，FilterInputStream的介面與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 {}
}查看原始碼，你會發現，這個裝飾類提供了額外的方法unread()，這就意味著PushbackInputStream是一個半透明的裝飾類，換言 之，它破壞了理想的裝飾模式的要求，如果客戶端持有一個型別為InputStream物件的參考in的話，那么如果in的真實型別是 PushbackInputStream的話，只要客戶端不需要使用unread()方法，那么客戶端一般沒有問題，但是如果客戶端必須使用這個方法，就 必須進行向下型別轉換，將in的型別轉換成為PushbackInputStream之后才可能呼叫這個方法，但是，這個型別轉換意味著客戶端必須知道它 拿到的參考是指向一個型別為PushbackInputStream的物件，這就破壞了使用裝飾模式的原始用意，
現實世界與理論總歸是有一段差距的，純粹的裝飾模式在真實的系統中很難找到，一般所遇到的，都是這種半透明的裝飾模式，
下面是使用I/O流讀取檔案內容的簡單操作示例，
public class IOTest {
public static void main(String[] args) throws IOException {
// 流式讀取檔案
DataInputStream dis = null;
try{
dis = new DataInputStream(
new BufferedInputStream(
new FileInputStream("test.txt")
)
);
//讀取檔案內容
byte[] bs = new byte[dis.available()];
dis.read(bs);
String content = new String(bs);
System.out.println(content);
}finally{
dis.close();
}
}
}觀察上面的代碼，會發現最里層是一個FileInputStream物件，然后把它傳遞給一個BufferedInputStream物件，經過BufferedInputStream處理，再把處理后的物件傳遞給了DataInputStream物件進行處理，這個程序其實就是裝飾器的組裝程序，FileInputStream物件相當于原始的被裝飾的物件，而BufferedInputStream物件和DataInputStream物件則相當于裝飾器，
（參考：《JAVA與模式》之裝飾模式）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8572.html
標籤：設計模式