天天學習一個設計模式（四）：結構型之裝飾模式

時間 2020-05-29

標籤天天學習一個設計模式構型裝飾简体版

原文原文鏈接

1、基本概念

裝飾模式又名包裝(Wrapper)模式。裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案。html

2、通俗解釋

DECORATOR裝飾模式：Mary過完輪到Sarly過生日，仍是不要叫她本身挑了，否則這個月伙食費確定玩完，拿出我去年在華山頂上照的照片，在背面寫上「最好的的禮物，就是愛你的Fita」，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，咱們都是Decorator，最終都在修飾我這我的呀，怎麼樣，看懂了嗎？裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增長功能，這些功能能夠再動態的撤消。增長由一些基本功能的排列組合而產生的很是大量的功能。java

3、分類

我把裝飾模式分爲兩類：純粹裝飾模式和簡化裝飾模式。我們實際應用中其實後者用的比較多，爲了弄清楚裝飾模式的含義，咱們先看純粹模式。設計模式

1.純粹裝飾模式的結構

裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任。換言之，客戶端並不會以爲對象在裝飾前和裝飾後有什麼不一樣。裝飾模式能夠在不使用創造更多子類的狀況下，將對象的功能加以擴展。app

裝飾模式的類圖以下：ide

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

●　抽象構件(Component)角色：給出一個抽象接口，以規範準備接收附加責任的對象。性能

●　具體構件(ConcreteComponent)角色：定義一個將要接收附加責任的類。this

●　裝飾(Decorator)角色：持有一個構件(Component)對象的實例，並定義一個與抽象構件接口一致的接口。url

●　具體裝飾(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）經過使用不一樣的具體裝飾類以及這些裝飾類的排列組合，設計師能夠創造出不少不一樣行爲的組合。

裝飾模式的缺點

因爲使用裝飾模式，能夠比使用繼承關係須要較少數目的類。使用較少的類，固然使設計比較易於進行。可是，在另外一方面，使用裝飾模式會產生比使用繼承關係更多的對象。更多的對象會使得查錯變得困難，特別是這些對象看上去都很相像。

4、設計模式在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與模式》之裝飾模式）