跳到主要內容

裝飾者模式 (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 則留言
閱讀完整內容

責任鏈模式 (Chain of Responsibility Pattern)

        假設你的公司時常會收到不同的電子郵件如垃圾信，顧客的抱怨信，顧客的感謝信等等，而公司希望對這些不同類型的信都先用制式的罐頭信回應 (就是 不同的信件有不同的處理方式 )。當你要寫程式處理公司的電子郵件時，直接寫在一個 class 是最簡單的作法。但你勢必會用到 if/else 或 switch 等來判斷不同的信件，而這樣做有一些缺點，例如 程式複雜性增加，不夠彈性，擴充困難 等等。當你希望 多個物件 (處理信的方式) 都有機會能處理相同請求時 (新寄來的電子郵件) 時，可以考慮責任鏈模式。先介紹此模式的正式定義及類別圖： 讓多個物件都有機會可以處理請求，以避免請求的發送者和接受者之間產生耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞請求，直到有一個物件處理這個請求為止。 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.         從類別圖來看這個模式很單純，每個子類別都有要實作的方法來處理它們能處理的特殊請求。 當有不能處理的請求時，也能傳給下一個子類別繼續處理 。當然這邊就是由設計者自行決定要有幾個子類別來處理哪些不同的請求，以及決定這些子類別傳遞請求的順序為何。         接著來看一下套用責任鏈模式的簡單程式碼吧 // 所有處理郵件的子類別要繼承的介面 public abstract class MailHandler { // 每個處理郵件類別都要記錄下一個 // 能處理的人是誰 protected MailHandler mHandler; public MailHandler(MailHandler handler) { mHandler = handl...
張貼留言
閱讀完整內容

代理人模式 (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...
張貼留言
閱讀完整內容