java設計模式－裝飾器模式(Decorator)

定義

裝飾器模式又名包裝(Wrapper)模式。裝飾器模式以對客戶端透明的方式擴充物件的功能，是繼承關係的一種替代方案。

裝飾器模式的結構

裝飾器模式以對客戶透明的方式動態的給一個物件附加上更多的責任。換言之，客戶端並不會覺得物件在裝飾前和裝飾後有什麼不同。裝飾器模式可以在不是用創造更多子類的情況下，將物件的功能加以擴充。

裝飾器模式的類圖如下：

在裝飾器模式中的角色有：

• 抽象構件(Component)角色：給出一個抽象介面，已規範準備接收附加責任的物件。
• 具體構件(ConcreteComponent)角色：定義一個將要接收附加責任的類
• 裝飾(Decorator)角色：持有一個構件(Component)物件的例項，並定義一個與抽象構件介面一致的介面。
• 具體裝飾(ConcreteDecorator)角色：負責給構件物件“貼上”附加的責任。

示例程式碼

抽象構件角色

public interface Component {
    public void sampleOpreation();
}

具體構件角色：

public class ConcreteComponent implements Component {
    @Override
    public void sampleOpreation() {
        // TODO 完成相關的業務程式碼
    }
}

裝飾角色

public class Decorator implements Component {
    private Component component;
    
    public Decorator(Component component) {
        this.component = component;
    }
    
    @Override
    public void sampleOpreation() {
        //委派給構件
        component.sampleOpreation();
    }

}

具體裝飾角色

public class ConcreteDecoratorA extends Decorator {
    public ConcreteDecoratorA(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOpreation() {
        super.sampleOpreation();
        //TODO 完成相關的業務程式碼
    }
}

public class ConcreteDecoratorB extends Decorator {
    public ConcreteDecoratorB(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOpreation() {
        super.sampleOpreation();
        //TODO 完成相關的業務程式碼
    }
}

齊天大聖的例子

孫悟空有七十二般變化，他的沒一種變化都給他帶來一種附加的本領。他變成魚兒時，就已到水裡游泳；他變成鳥兒時，就可以在天上飛行。

本例中，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() {
        this.sage.move();
    }
}

具體裝飾角色，“魚兒”和“鳥兒”

public class Fish extends Change {
    public Fish(TheGreatestSage sage) {
        super(sage);
    }
    
    @Override
    public void move() {
        super.move();
        System.out.println("Change fish move");
    }
}

public class Bird extends Change {
    public Bird(TheGreatestSage sage) {
        super(sage);
    }
    
    @Override
    public void move() {
        super.move();
        System.out.println("Change bird move");
    }
}

客戶端類

public class Client {
    public static void main(String[] args) {
        TheGreatestSage sage = new Monkey();
        //第一種寫法
        TheGreatestSage bird = new Bird(sage);
        bird.move();
        
        //第二種寫法
        TheGreatestSage fish = new Fish(new Bird(sage));
        fish.move();
    }
}

大聖本尊是ConcreteComponent類，而“鳥兒”、“魚兒”是裝飾類，要裝飾的是大聖本尊，也就是猢猻類例項。

上面的例子中，系統把大聖從一直猢猻裝飾成一隻鳥兒（把鳥兒的功能加到了猢猻身上），然後又把鳥兒裝飾成一條魚兒（把魚兒的功能裝飾到猢猻+鳥兒身上），從而得到最終呈現猢猻+鳥兒+魚兒的結果。

如上圖所示，大聖的變化首先將鳥兒的功能附加到猢猻身上，然後又將魚兒的功能附加到猢猻+鳥兒身上。

裝飾模式的簡化

大多數情況下，裝飾模式的實現都要比上面的示意性例子要簡單。

如果只有一個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、StringBufferInputStream等類扮演。它們實現了抽象構件角色所規定的介面。
• 抽象裝飾角色(Decorator)：由FilterInputStream、ObectInputStream等類扮演。它們實現了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 {
        return read(b, 0, b.length);
    }
    
    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 {
        throw new IOException("mark/reset not supported");
    }
    
    public boolean markSupported() {
        return false;
    }
}

下面是作為裝飾模式的抽象裝飾角色FilterInputStream類的原始碼。可以看出，FilterInputStream的介面與InputStream的介面是完全一致的，也就是說，直到這一步，還是與裝飾模式相吻合的。

public class FilterInputStream extends InputStream {
    public int read() throws IOException {
        return in.read();
    }
    
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }
    
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }
    
    public long skip(long n) throws IOException {
        return in.skip(n);
    }
    
    public int available() throws IOException {
        return in.available();
    }
    
    public void close() throws IOException {
        in.close();
    }
    
    public synchronized void mark(int readlimit) {
        in.mark(readlimit);
    }
    
    public synchronized void reset() throws IOException {
        in.reset();
    }
    
    public boolean markSupported() {
        return in.markSupported();
    }
}

下面是具體裝飾角色PushbackInputStream的原始碼：

public class PushbackInputStream extends FilterInputStream {
    private void ensureOpen() throws IOException {
        if (in == null)
            throw new IOException("Stream closed");
    }
    
    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 {
        unread(b, 0, b.length);
    }
    
    public int available() throws IOException {
        //……
    }
    
    public long skip(long n) throws IOException {
        //……
    }
    
    public boolean markSupported() {
        return false;
    }
    
    public synchronized void mark(int readlimit) {
    }
    
    public synchronized void reset() throws IOException {
        throw new IOException("mark/reset not supported");
    }
    
    public synchronized void close() throws IOException {
        //……
    }
}

通過檢視原始碼，你會發現，這個裝飾類提供了額外的方法unread()，這就意味著PushbackInputStream是一個半透明的裝飾類。換句話說，它破壞了理想的裝飾模式的要求。如果客戶端持有一個型別為InputStream物件的引用in的話，那麼如果in的真實型別是PushbackInputStream的話，只要客戶端不需要使用unread()方法，那麼客戶端一般沒有問題。但是如果客戶端必須使用這個方法，就必須進行向下型別轉換。將in的型別轉換成為PushbackInputStream之後才可能呼叫這個方法。但是，這個型別轉換意味著客戶端必須知道它拿到的引用是指向一個型別為PushbackInputStream的物件。這就破壞了使用裝飾模式的原始用意。

現實世界與理論總歸是有一段差距的。純粹的裝飾模式在真實的系統中很難找到。一般所遇到的，都是這種半透明的裝飾模式。

示例程式

下面是使用I/O流讀取檔案內容的簡單示例

import java.io.BufferedInputStream;
import java.io.DataInputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

public class InputStreamTest {
    public static void main(String[] args) {
        DataInputStream dis = null;
        try {
            dis = new DataInputStream(
                    new BufferedInputStream(
                            new FileInputStream("23.txt")
                            )
                    );
            byte[] bytes = new byte[dis.available()];
            dis.read(bytes);
            String content = new String(bytes);
            System.out.println(content);
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                dis.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

觀察上面的程式碼，會發現最裡層是一個FileInputStream物件，然後把它傳遞給一個BufferedInputStream物件，經過BufferedInputStream物件處理後，再將處理後的物件傳遞給DataInputStream物件進行處理。這個過程，其實就是裝飾器的組裝過程，FileInputStream物件相當於原始的被裝飾的物件，而BufferedInputStream物件和DataInputStream物件則相當於裝飾器。

參考

《JAVA與模式》之裝飾模式