08.裝飾者模式設計思想

目錄介紹

01.裝飾者模式基礎
- 1.1 裝飾者模式由來
- 1.2 裝飾者模式定義
- 1.3 裝飾者模式場景
- 1.4 裝飾者模式思考
02.裝飾者模式實現
- 2.1 羅列一個場景
- 2.2 裝飾者結構
- 2.3 裝飾者基本實現
03.裝飾者例項演示
- 3.1 需求分析
- 3.2 案例基礎實現
- 3.3 演變設計思想
- 3.4 使用裝飾者模式
- 3.5 裝飾器能否精簡
- 3.6 透明性的要求
- 3.7 半透明裝飾者模式
04.裝飾器模式場景
- 4.1 IO流中裝飾者模式
- 4.2 IO流設計結構
- 4.3 半透明裝飾者模式
- 4.4 InputStream裝飾者模式
05.裝飾器模式分析
- 5.1 裝飾模式優點
- 5.2 裝飾模式缺點
- 5.3 總結一下學習
- 5.4 更多內容推薦

01.裝飾者模式基礎

1.0 本部落格AI摘要

裝飾者模式是一種設計模式，用於在不修改原始類的情況下動態地給物件新增新功能。本文件詳細介紹了裝飾者模式的基礎概念、實現方法、應用場景及優缺點。透過具體的咖啡示例和Java I/O流中的應用，展示了裝飾者模式的靈活性和實用性。此外，還探討了半透明裝飾者模式的概念及其在實際開發中的應用。適合初學者和有一定經驗的開發者學習。

1.1 裝飾者模式由來

一般有兩種方式可以實現給一個類或物件增加行為：

繼承機制，使用繼承機制是給現有類新增功能的一種有效途徑，透過繼承一個現有類可以使得子類在擁有自身方法的同時還擁有父類的方法。但是這種方法是靜態的，使用者不能控制增加行為的方式和時機。
關聯機制，即將一個類的物件嵌入另一個物件中，由另一個物件來決定是否呼叫嵌入物件的行為以便擴充套件自己的行為，我們稱這個嵌入的物件為裝飾器(Decorator)

裝飾模式以對客戶透明的方式動態地給一個物件附加上更多的責任，換言之，客戶端並不會覺得物件在裝飾前和裝飾後有什麼不同。

裝飾模式可以在不需要創造更多子類的情況下，將物件的功能加以擴充套件。這就是裝飾模式的模式動機。

1.2 裝飾者模式定義

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

裝飾者模式動態地將責任附加到物件身上。若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。

1.3 裝飾者模式場景

裝飾者模式適用於以下場景：

動態地給一個物件新增額外的功能，而不需要修改其原始類的程式碼。裝飾者模式允許在執行時動態地新增、修改或刪除物件的行為。
需要擴充套件一個類的功能，但是使用繼承會導致類的數量急劇增加。透過裝飾者模式，可以避免建立大量的子類，而是透過組合不同的裝飾器來實現功能的擴充套件。
需要在不影響其他物件的情況下，對物件的功能進行動態組合和排列。裝飾者模式可以透過不同的裝飾器組合來實現不同的功能組合，而不需要修改原始物件或其他裝飾器。

裝飾者模式常見的應用場景包括：

Java中IO流操作中的裝飾者模式、Swing GUI元件中的裝飾者模式、Java I/O庫中的BufferedInputStream和BufferedOutputStream等。
Android中自定義View的功能擴充套件、RecyclerView的ItemDecoration、Fragment的功能增強等。
其他日誌功能，日誌記錄功能的實現也是裝飾者模式的理想應用場景。例如，傳統的日誌記錄器Logger可以透過裝飾者模式新增不同的日誌處理和記錄策略，如格式化日誌、輸出到檔案、傳送電子郵件等。

1.4 裝飾者模式思考

當考慮使用裝飾者模式時，可以思考以下幾個方面：更多內容

是否需要在執行時動態地新增、修改或刪除物件的行為？如果是的話，裝飾者模式符合要求
需要擴充套件一個類的功能，但是使用繼承會導致類的數量急劇增加嗎？如果是的話，裝飾者模式可以透過組合不同的裝飾器來實現功能的擴充套件，而不需要建立大量的子類。
是否需要為一個物件的不同部分或屬性提供獨立的擴充套件？如果是的話，裝飾者模式允許對物件的不同部分進行獨立的擴充套件，而不會影響其他部分。

02.裝飾者模式實現

2.1 羅列一個場景

我們將以一個具體的咖啡示例來介紹裝飾者模式的實現。在這個例子中，我們有一個基本的咖啡物件，可以動態地新增不同的配料（如牛奶和糖）。更多內容

比如：

咖啡A，加牛奶和半糖
咖啡B，加牛奶和全糖
咖啡C，加牛奶和多糖
咖啡D，不加牛奶和半糖

2.2 裝飾者結構

裝飾者模式以對客戶透明的方式動態地給一個物件附加上更多的責任。

換言之，客戶端並不會覺得物件在裝飾前和裝飾後有什麼不同。裝飾者模式可以在不使用創造更多子類的情況下，將物件的功能加以擴充套件。

在裝飾模式中的角色有：更多內容

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

2.3 裝飾者基本實現

抽象構件角色

// Java實現
public interface Coffee {
    double cost();
    String getDescription();
}

具體構件角色

public class SimpleCoffee implements Coffee {
    public double cost() {
        return 5.0;
    }
    
    public String getDescription() {
        return "Simple Coffee";
    }
}

裝飾角色

public abstract class CoffeeDecorator implements Coffee {
    protected Coffee coffee;

    public CoffeeDecorator(Coffee coffee) {
        this.coffee = coffee;
    }
    
    public double cost() {
        return coffee.cost();
    }
    
    public String getDescription() {
        return coffee.getDescription();
    }
}

具體裝飾角色

public class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) {
        super(coffee);
    }

    public double cost() {
        return super.cost() + 1.5;
    }
    
    public String getDescription() {
        return super.getDescription() + ", Milk";
    }
}

public class SugarDecorator extends CoffeeDecorator {
    public SugarDecorator(Coffee coffee) {
        super(coffee);
    }

    public double cost() {
        return super.cost() + 0.5;
    }
    
    public String getDescription() {
        return super.getDescription() + ", Sugar";
    }
}

使用裝飾者模式

private void test1() {
    Coffee coffee = new SimpleCoffee();
    System.out.println(coffee.getDescription() + " Cost: $" + coffee.cost());

    coffee = new MilkDecorator(coffee);
    System.out.println(coffee.getDescription() + " Cost: $" + coffee.cost());

    coffee = new SugarDecorator(coffee);
    System.out.println(coffee.getDescription() + " Cost: $" + coffee.cost());
}

03.裝飾者例項演示

3.1 需求分析

齊天大聖的例子

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

3.2 案例基礎實現

3.3 演變設計思想

3.4 使用裝飾者模式

本例中，Component的角色便由鼎鼎大名的齊天大聖扮演；ConcreteComponent的角色屬於大聖的本尊，就是猢猻本人；Decorator的角色由大聖的七十二變扮演。而ConcreteDecorator的角色便是魚兒、鳥兒等七十二般變化。

抽象構件角色“齊天大聖”介面定義了一個move()方法，這是所有的具體構件類和裝飾類必須實現的。

//大聖的尊號
public interface TheGreatestSage {
    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類，而“鳥兒”、“魚兒”是裝飾類。要裝飾的是“大聖本尊”，也即“猢猻”例項。

上面的例子中，第二種些方法：系統把大聖從一隻猢猻裝飾成了一隻鳥兒（把鳥兒的功能加到了猢猻身上），然後又把鳥兒裝飾成了一條魚兒（把魚兒的功能加到了猢猻+鳥兒身上，得到了猢猻+鳥兒+魚兒）。

3.5 裝飾器能否精簡

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

如果只有一個ConcreteComponent類，那麼可以考慮去掉抽象的Component類（介面），把Decorator作為一個ConcreteComponent子類。

如果只有一個ConcreteDecorator類，那麼就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合併成一個類。甚至在只有兩個ConcreteDecorator類的情況下，都可以這樣做。

3.6 透明性的要求

裝飾者模式的透明性要求是指在使用裝飾者模式時，對於客戶端來說，應該能夠透明地使用原始物件和裝飾器物件，而不需要關心具體的物件型別。

裝飾者模式對客戶端的透明性要求程式不要宣告一個ConcreteComponent型別的變數，而應當宣告一個Component型別的變數。

用孫悟空的例子來說，必須永遠把孫悟空的所有變化都當成孫悟空來對待，而如果把老孫變成的魚兒當成魚兒，而不是老孫，那就被老孫騙了，而這時不應當發生的。下面的做法是對的：

TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);

而下面的做法是不對的：

Monkey sage = new Monkey();
Bird bird = new Bird(sage);

在實際應用中，可能會因為裝飾器物件的巢狀而導致透明性的破壞。因此，在使用裝飾者模式時，需要權衡透明性和複雜性，並根據具體的需求和情況做出決策。

3.7 半透明裝飾者模式

然而，純粹的裝飾者模式很難找到。裝飾者模式的用意是在不改變介面的前提下，增強所考慮的類的效能。在增強效能的時候，往往需要建立新的公開的方法。更多內容

即便是在孫大聖的系統裡，也需要新的方法。比如齊天大聖類並沒有飛行的能力，而鳥兒有。這就意味著鳥兒應當有一個新的fly()方法。再比如，齊天大聖類並沒有游泳的能力，而魚兒有，這就意味著在魚兒類裡應當有一個新的swim()方法。

這就導致了大多數的裝飾者模式的實現都是“半透明”的，而不是完全透明的。換言之，允許裝飾者模式改變介面，增加新的方法。這意味著客戶端可以宣告ConcreteDecorator型別的變數，從而可以呼叫ConcreteDecorator類中才有的方法：

TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();

半透明的裝飾者模式是介於裝飾者模式和介面卡模式之間的。介面卡模式的用意是改變所考慮的類的介面，也可以透過改寫一個或幾個方法，或增加新的方法來增強或改變所考慮的類的功能。大多數的裝飾者模式實際上是半透明的裝飾者模式，這樣的裝飾者模式也稱做半裝飾、半介面卡模式。

04.裝飾器模式場景

4.1 IO流中裝飾者模式

裝飾者模式在Java語言中的最著名的應用莫過於Java I/O標準庫的設計了。

由於Java I/O庫需要很多效能的各種組合，如果這些效能都是用繼承的方法實現的，那麼每一種組合都需要一個類，這樣就會造成大量效能重複的類出現。而如果採用裝飾者模式，那麼類的數目就會大大減少，效能的重複也可以減至最少。因此裝飾者模式是Java I/O庫的基本模式。

Java I/O庫的物件結構圖如下，由於Java I/O的物件眾多，因此只畫出InputStream的部分。

InputStream是最上層的父類，表示位元組流
FileInputStream是一個具體類，用來對檔案進行讀取
BufferedInputStream是位元組緩衝流，主要是為了減少I/O操作的次數，提高效率。

4.2 IO流設計結構

IO流中裝飾者模式結構如下所示：更多內容

抽象構件(Component)角色：由InputStream扮演。這是一個抽象類，為各種子型別提供統一的介面。
具體構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實現了抽象構件角色所規定的介面。
抽象裝飾(Decorator)角色：由FilterInputStream扮演。它實現了InputStream所規定的介面。
具體裝飾(ConcreteDecorator)角色：由幾個類扮演，分別是BufferedInputStream、DataInputStream以及兩個不常用到的類LineNumberInputStream、PushbackInputStream。

4.3 半透明裝飾者模式

裝飾者模式和介面卡模式都是“包裝模式(Wrapper Pattern)”，它們都是透過封裝其他物件達到設計的目的的，但是它們的形態有很大區別。

理想的裝飾者模式在對被裝飾物件進行功能增強的同時，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致。而介面卡模式則不然，一般而言，介面卡模式並不要求對源物件的功能進行增強，但是會改變源物件的介面，以便和目標介面相符合。

裝飾者模式有透明和半透明兩種，這兩種的區別就在於裝飾角色的介面與抽象構件角色的介面是否完全一致。透明的裝飾者模式也就是理想的裝飾者模式，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致。相反，如果裝飾角色的介面與抽象構件角色介面不一致，也就是說裝飾角色的介面比抽象構件角色的介面寬的話，裝飾角色實際上已經成了一個介面卡角色，這種裝飾者模式也是可以接受的，稱為“半透明”的裝飾模式。

在介面卡模式裡面，介面卡類的介面通常會與目標類的介面重疊，但往往並不完全相同。換言之，介面卡類的介面會比被裝飾的目標類介面寬。更多內容

顯然，半透明的裝飾者模式實際上就是處於介面卡模式與裝飾者模式之間的灰色地帶。如果將裝飾者模式與介面卡模式合併成為一個“包裝模式”的話，那麼半透明的裝飾者模式倒可以成為這種合併後的“包裝模式”的代表。

4.4 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 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物件則相當於裝飾器。更多內容

05.裝飾器模式分析

5.1 裝飾模式優點

1）裝飾模式與繼承關係的目的都是要擴充套件物件的功能，但是裝飾模式可以提供比繼承更多的靈活性。裝飾模式允許系統動態決定“貼上”一個需要的“裝飾”，或者除掉一個不需要的“裝飾”。繼承關係則不同，繼承關係是靜態的，它在系統執行前就決定了。
2）透過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合。

5.2 裝飾模式缺點

由於使用裝飾模式，可以比使用繼承關係需要較少數目的類。使用較少的類，當然使設計比較易於進行。更多內容，但是，在另一方面，使用裝飾模式會產生比使用繼承關係更多的物件。更多的物件會使得查錯變得困難，特別是這些物件看上去都很相像。

5.3 總結一下學習

01.裝飾者模式基礎

給一個類或者物件增加行為：1.繼承，子類透過重寫父類方法修改行為。2.關聯機制，將一個類的物件嵌入另一個物件中用於行為擴充。

裝飾者模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案。

裝飾者模式適用於以下場景：更多內容

動態地給一個物件新增額外的功能，而不需要修改其原始類的程式碼。
需要擴充套件一個類的功能，但是使用繼承會導致類的數量急劇增加。
需要在不影響其他物件的情況下，對物件的功能進行動態組合和排列。

02.裝飾者模式實現

比如：有一個基本的咖啡物件，可以動態地新增不同的配料（如牛奶和糖）。在不改變物件情況下，對行為進行擴充！

咖啡A，加牛奶和半糖
咖啡B，加牛奶和全糖
咖啡C，加牛奶和多糖
咖啡D，不加牛奶和半糖

在裝飾模式中的角色有：

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

03.裝飾者例項演示

04.裝飾器模式場景

裝飾者模式在Java語言中的最著名的應用莫過於Java I/O標準庫的設計了。

IO流中裝飾者模式結構如下所示：

抽象構件(Component)角色：由InputStream扮演。這是一個抽象類，為各種子型別提供統一的介面。
具體構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實現了抽象構件角色所規定的介面。
抽象裝飾(Decorator)角色：由FilterInputStream扮演。它實現了InputStream所規定的介面。
具體裝飾(ConcreteDecorator)角色：由幾個類扮演，分別是BufferedInputStream、DataInputStream以及兩個不常用到的類LineNumberInputStream、PushbackInputStream。

5.4 更多內容推薦

模組	描述	備註
GitHub	多個YC系列開源專案，包含Android元件庫，以及多個案例	GitHub
部落格彙總	匯聚Java，Android，C/C++，網路協議，演算法，程式設計總結等	YCBlogs
設計模式	六大設計原則，23種設計模式，設計模式案例，物件導向思想	設計模式
Java進階	資料設計和原理，物件導向核心思想，IO，異常，執行緒和併發，JVM	Java高階
網路協議	網路實際案例，網路原理和分層，Https，網路請求，故障排查	網路協議
計算機原理	計算機組成結構，框架，儲存器，CPU設計，記憶體設計，指令程式設計原理，異常處理機制，IO操作和原理	計算機基礎
學習C程式設計	C語言入門級別系統全面的學習教程，學習三到四個綜合案例	C程式設計
C++程式設計	C++語言入門級別系統全面的教學教程，併發程式設計，核心原理	C++程式設計
演算法實踐	專欄，陣列，連結串列，棧，佇列，樹，雜湊，遞迴，查詢，排序等	Leetcode
Android	基礎入門，開源庫解讀，效能最佳化，Framework，方案設計	Android

23種設計模式

23種設計模式 & 描述 & 核心作用	包括
建立型模式提供建立物件用例。能夠將軟體模組中物件的建立和物件的使用分離	工廠模式（Factory Pattern）抽象工廠模式（Abstract Factory Pattern）單例模式（Singleton Pattern）建造者模式（Builder Pattern）原型模式（Prototype Pattern）
結構型模式關注類和物件的組合。描述如何將類或者物件結合在一起形成更大的結構	介面卡模式（Adapter Pattern）橋接模式（Bridge Pattern）過濾器模式（Filter、Criteria Pattern）組合模式（Composite Pattern）裝飾器模式（Decorator Pattern）外觀模式（Facade Pattern）享元模式（Flyweight Pattern）代理模式（Proxy Pattern）
行為型模式特別關注物件之間的通訊。主要解決的就是“類或物件之間的互動”問題	責任鏈模式（Chain of Responsibility Pattern）命令模式（Command Pattern）直譯器模式（Interpreter Pattern）迭代器模式（Iterator Pattern）中介者模式（Mediator Pattern）備忘錄模式（Memento Pattern）觀察者模式（Observer Pattern）狀態模式（State Pattern）空物件模式（Null Object Pattern）策略模式（Strategy Pattern）模板模式（Template Pattern）訪問者模式（Visitor Pattern）

5.5 更多內容

GitHub：https://github.com/yangchong211
我的程式設計網站：https://yccoding.com
部落格彙總：https://github.com/yangchong211/YCBlogs
設計模式專欄：https://github.com/yangchong211/YCDesignBlog
Java高階進階專欄：https://github.com/yangchong211/YCJavaBlog
網路協議專欄：https://github.com/yangchong211/YCNetwork
計算機基礎原理專欄：https://github.com/yangchong211/YCComputerBlog

08.裝飾者模式設計思想