假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…
以下是目前菜單的類別圖:
簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。
買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha,就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。
換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則:
後記:
在 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)
以下是目前菜單的類別圖:
簡單說明此類別圖, 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)
留言
張貼留言