跳到主要內容

裝飾者模式 (Decorator Pattern)

        假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…
        以下是目前菜單的類別圖:

        簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。

        買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha，就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。

        換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則:

類別應該開放, 以便擴充 ; 應該關閉, 禁止修改。

        我們的目標是允許類別容易擴充, 在不修改現有程式碼的情形就能搭配新的行為。這樣的設計具有彈性, 可以接受新功能以達到改變需求的目的。這看起來好像有點矛盾, 但是的確有一些技術可以在不直接修改程式碼的情形下進行擴充, 如裝飾者模式。

        這時候應該有人會問: 那是不是以後我的專案架構設計都遵循這個守則就是好設計了 ? 答案是不太可能, 也沒這必要, 就算做得到, 也可能是浪費, 容易導致程式碼複雜且難以理解。只需小心選擇哪些部分未來會擴充, 這些部份遵循這個設計守則即可。

        接下來正式介紹裝飾者模式的定義: 

裝飾者模式動態地將責任加諸於物件上。若要擴充功能，裝飾者模提供了比繼承更有彈性的選擇
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.



  • Decorator 是裝飾者共同實作的介面, 也可以是抽象類別
  • 每個元件都可以單獨使用, 或是被裝飾者包起來使用
  • 裝飾者可以擴充元件的狀態及行為
  • ConcreteDecorator 有一個實體變數, 可以記錄所裝飾的元件

        接下來看看搭配裝飾者模式的新菜單吧:


  • Beverage 如同抽象的 Component 類別 (也可以是介面)
  • DarkRoast, Espresso 是具體元件, 個別代表一種咖啡
  • Milk, Mocha 是配料裝飾者
  • CondimentDecorator 繼承 Beverage 是為了讓裝飾者與被裝飾者有相同的型態, 而不是相同的行為。新增加的行為, 是從裝飾者跟元件合成時所產生的合成物件而來。利用合成, 可以把裝飾者混合著用, 而且是在執行時期動態地進行。


        程式上的概念大致上是這樣: 假如有客人要點 Espresso, 且摩卡牛奶各加一份, 我們就是先準備好 Espresso 元件, 把 Espresso 元件用摩卡裝飾(Espresso 元件代入摩卡裝飾者), 把 Espresso 元件 + 摩卡後的合成元件再用牛奶裝飾(行為跟用摩卡裝飾是一樣的)。概念都清楚的話, 就可以來看看程式碼了:

public abstract class Beverage {
    String description = "Unknown Beverage"

    public String getDescription()
    {
        return description;
    }

    // 留給子類別實作
    public abstract double cost();
}


public abstract class CondimentDecorator extends Beverage {

    // 因為希望配料也能顯示出來,
    // 因此所有子類別都要實作這個 method
    public abstract String getDescription();
}


public class Espresso extends Beverage {

    public Espresso
    {
        // 這個變數是繼承自 Beverage 的
        description = "Espresso";
    }

    public double cost()
    {
        // 目前這邊只是單純 Espresso 的價格,
        // 不含任何配料
        return 1.99;
    }
}


// 摩卡是一個裝飾者, 因此讓它繼承自 CondimentDecorator
// 而且別忘了, CondimentDecorator 繼承自 Beverage 喔
public class Mocha extends CondimentDecorator {

    // 要讓摩卡能參考到 Beverage,
    // 因此需要這個成員變數
    Beverage mBeverage;

    public Mocha(Beverage beverage)
    {
        this.mBeverage = beverage;
    }

    // 以下兩個 method 的作法都是利用委派(delegation) 的方式,
    // 從被裝飾者拿到資訊後, 再加上裝飾者的資訊
    public String getDescription()
    {
        return mBeverage.getDescription() + ", Mocha";
    }

    public double cost()
    {
        return .20 + mBeverage.cost();
    }
}


// 牛奶裝飾者基本上寫法跟摩卡裝飾者一樣
public class Milk extends CondimentDecorator {

    Beverage mBeverage;

    public Mocha(Beverage beverage)
    {
        this.mBeverage = beverage;
    }

    public String getDescription()
    {
        return mBeverage.getDescription() + ", Milk";
    }

    public double cost()
    {
        return .30 + mBeverage.cost();
    }
}


public class BeverageTest {

    pubilc static void main(String[] args)
    {
        // 點了一杯 Espresso, 印出它的資訊
        Beverage beverage = new Espresso();
        System.out.println(beverage.getDescription() +
            " $" + beverage.cost());

        // 再點一杯 Espresso
        Beverage beverage2 = new Espresso();

        // 用摩卡裝飾 Espresso
        beverage2 = new Mocha(beverage2);

        // 用牛奶裝飾加了摩卡的 Espresso
        beverage2 = new Milk(beverage2);
        System.out.println(beverage2.getDescription() +
            " $" + beverage2.cost());
    }
}

後記:
        在 Java API 中, 最常看到裝飾者模式的就是 Java I/O。舉例來說,
BufferedReader br = new BufferedReader(new FileReader("file.txt")) 可以明顯看出, BufferedReader 就是一個用來裝飾 FileReader 的 class。當然要新增自己專用的 FileReader 也可以, 而且自己新增的也都不會影響到原本就有的 FileReader。

        不過 Java I/O 也引出裝飾者模式的一個缺點: 容易造成設計中有大量小類別。數量太多容易造成使用上的困擾。

參考資料:

深入淺出設計模式(Head First Design Patterns)
標籤：

留言

張貼留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統，其中會有一些相似類別，類別中都有某些方法內容相似，但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情，在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷，如以下的簡單範例： public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...
1 則留言
閱讀完整內容

解譯器模式 (Interpreter Pattern)

        解譯器模式簡單來說就是 把一句有特殊規則的語句，透過解釋器將它真正的意思表現出來 。相信有學過 Context-free grammar (CFG)，Backus–Naur form (BNF)，或是 Compiler 相關程的人會比較了解這個模式 (不是我，我早就忘光了…)。不知道上面術語的人，還是可以透過接下來的介紹來稍微了解這個模式。先來看一下這個模式的正式定義及類別圖： 定義一個語言與其文法，使用一個解譯器來表示這個語言的敘述 Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language Context 通常是指待解譯的語句 AbstractExpression 是所有規則都要實作的介面 TerminalExpression 是指無法再展開的規則，算是最小單位的規則 NonterminalExpression 是指可以再展開的規則，可以展開成 NonterninalExpression 和 TerminalExpression 的組合         從類別圖可以看到，語法可能可以一直展開，這時就可以用語法樹來表示，而語法樹以程式來表達的話，就可以使用 合成模式 。而通常比較正式的語法會用 BNF 來表示，如下： expression ::= plus | minus | variable | number plus ::= expression expression '+' minus ::= expression expression '-' variable ::= 'a' | 'b' | 'c' | ... | 'z' digit = '0' | '1' | ... | '9' number ::= digit | digit number 而 每個語法都會定義一個類別 ，如 pl...
2 則留言
閱讀完整內容

代理人模式 (Proxy Pattern)

        代理人模式如同字面上的意思，就是做事情時(如取得某些資料)，是透過代理人，而不是直接跟提供資料的物件構通。先來看看此模式的正式定義及類別圖： 代理人模式讓某個物件具有一個替身，藉以控制外界對此物件的影響。 Provide a surrogate or placeholder for another object to control access to it.         從類別圖可以看到， Subject 是共用的介面，可以讓客戶 將 Proxy 物件視為 RealSubject 物件 來處理。RealSubject 是真正做事的物件，被 Proxy 代理， Proxy 可以控制 RealSubject 的存取 。Proxy 持有 RealSubject 的參考，客戶和 RealSubject 的互動都要透過 Proxy，在某些情形下這樣的限制是必要的，如 RealSubject 是遠端物件， RealSubject 建立成本高等等。         此模式有許多種變形，都是依據上面的原則而發展出來的。以下介紹  深入淺出設計模式(Head First Design Patterns) 裡面提到的一些應用方式：         1. 遠端代理人(Remote) ：算是最常使用到的應用方式。在網路中或是跨 Process 的各種程式，不可能直接存取(assess) 不同程式間的物件，因此就需要遠端代理人。 Java RMI  和 Android AIDL  都算是遠端代理人的實踐。         2. 虛擬代理人(Virtual) ：代理的對象是建立很花費資源的物件。當物件建立前和建立中，由虛擬代理人扮演代理的角色。物件建立完成後，代理人就會將讓求直接轉給物件。以下為簡單範例程式： // Proxy 實作跟 RealSubject 共同的介面 Icon public class ImageProxy implements Icon { // 這是我們的 RealSubje...
張貼留言
閱讀完整內容