Decorator Design Pattern（3）套用 Decorator Pattern

Decorator Design Pattern（2）I/O Stream API << 前情

Code＆ Data 是一個不錯的技術網站

Simon在逛購物網站的時候，無意中發現一個技術網站http://www.codedata.com.tw。網站裡有一個討論「Decorator」設計模式的系列專欄，裡面說到Java內建的串流架構就是一種「Decorator」的設計方式。所以他決定參考這樣的設計方式：

如果這樣的設計方式行得通，那不論有多少早餐或配料，都不會影響到原來已經設計好的類別：

Breakfast 與它的子類別

Simon在畫出上列兩個圖型以後，他決定可以開始把程式實作出來看看。首先當然是「Breakfast」類別：

使用這樣的設計方法，早餐類別的設計就會單純多了：

Comdiment 與它的子類別

配料類別雖然好像是一個獨立的繼承架構，不過Simon讓它也繼承自「Breakfast」：

火腿三明治賣得不錯，那就從這個配料類別開始：

火腿三明治加蛋也是賣得很好的一種早餐，也先把加蛋的類別加進來：

試試看

寫完這幾個類別以後，Simon想著：應該可以先試試看了。

雖然結果是正確的，不過Simon還是畫了一個圖型來確認一下這些類別合作的過程：

關於Decorator Pattern

目的

提供附加的功能給物件，可以避免修改原來的程式碼就可以彈性的增加功能。

別名

Wrapper、包裝者。

時機

• 想要在執行時期增加物件額外的功能，但是不會影響到其它的物件。
• 希望增加物件功能時，仍然可以保留物件原來的特性。
• 不希望繼承架構過於龐大。
• 不希望子類別繼承一些不會使用到的特性。

效果

• 比繼承架構更靈活。繼承屬於「編譯時期」的作法，而Decorator屬於「執行時期」的作法。
• 避免子類別繼承一些用不到的特性。
• 物件可能會太多。

結構

後續 >> Decorator Design Pattern（4）Simon 的筆記與你的練習