設計模式使用的例子
動態地給乙個物件增加一些額外的職責，就增加物件功能來說，裝飾模式遠比生成子類實現更加靈活。裝飾模式是一種物件結構型模式。
component （抽象構件）：具體構件和抽象裝飾類的基類，宣告了在具體構建中實現的業務方法。
concretecomponent（具體構件）：抽象構件的子類，用於定義具體的構件物件，實現了在抽象構件中宣告的方法，裝飾器可以給它增加額外的職責（方法）。
decorator（抽象裝飾類）：它也是抽象構件類的子類，用於給具體構件增加職責，但是具體職責在其子類中實現。
concretedecorator（具體裝飾類）：抽象裝飾類的子類，負責向構件新增新的職責。
對於擴充套件乙個物件的功能，裝飾模式比繼承更加靈活，不會導致類的個數急劇增加！
可以對乙個物件進行多次裝飾，從而創造出很多不同行為的組合，得到功能更為強大的物件！
具體構件類與具體裝飾類可以獨立變化，可以根據需要增加新的具體構建和具體裝飾，原有**無需修改，符合開放封閉原則！
雖然裝飾模式拱了一種比繼承更加靈活機動的方案，但同時也意味著比繼承更加易於出錯，排錯也很困難。
特別是經過多次裝飾的物件，除錯時尋找錯誤可能需要逐級排查，較為繁瑣。
在不影響其他物件的情況下，想要動態地、透明地給單個物件新增職責
當不能採用繼承的方式對系統進行擴充套件 或 採取繼承不利於系統擴充套件和維護時
1、通過購買奶茶的例子來理解裝飾模式，顧客買一杯奶茶，你需要給出對這個奶茶的描述和**。
如果不使用裝飾模式，那麼我們會設計乙個奶茶的父類，帶有基本的描述和最基本奶茶的**。
其他種類的奶茶，如珍珠奶茶則會繼承自這個父類，然後重寫父類的方法，新增自己的描述和**。
遇到的問題：
* 1、如果出乙個新的奶茶品種，就需要新加入乙個類，那麼如果有100種奶茶就有100個類
* 2、如果需要加雙份的椰果奶茶，怎麼辦？如果需要無糖奶茶的呢？
* 3、如果**要臨時變動怎麼辦？
如果使用裝飾模式，那麼我們可以動態的給單個物件多次的裝飾，組成不同的樣子的同一種物件
比如你需要珍珠奶茶，就用珍珠去裝飾奶茶；你需要雙份椰果奶茶，就用椰果裝飾兩次。
2、對於component（抽象構件）來說，它是被裝飾的基本單位，而concretecomponent（具體構件）則是它不同的表現形式
同樣的，decorator（抽象裝飾）是最基本的裝飾單位，它要求每個具體裝飾類都必須做的事情，如這裡的說明。
具體來說，在使用的時候，對於乙個物件來說對於有本質上面區別的，使用不同的具體構建；
而只是對其進行裝飾（修飾）的，使用不同的具體裝飾。
還有乙個重要區別是，構件只能被構建一次，也就直接決定了物件的主要性質，而裝飾可以進行多次。
參考部落格：
設計模式3 裝飾者模式
動態的將責任附加到物件上。想要擴充套件功能，裝飾者提供有別於繼承的另一種選擇 封裝變化 多用組合，少用繼承 針對介面程式設計，不針對實現程式設計 為互動物件之間的松耦合設計而努力 對擴充套件開放，對修改關閉 在購買咖啡時，可以要求在其中加入各種調料，例如 蒸奶，豆漿，摩卡等其他調料，會根據加入的不同...
設計模式 （3）裝飾者模式
動態的將責任附加到物件上，在擴充套件功能上，裝飾者提供了比繼承更有彈性的替代方案。維護了開放封閉原則 對擴充套件開放，對修改封閉 將裝飾者和具體元件組合，就是在加入新的行為。組合和委託可以在執行時動態的加上新的行為。而繼承雖然也屬於擴充套件形式之一，但是非彈性設計，而且依賴繼承，類的行為只能在編譯時...
設計模式3 裝飾者模式
0.序 裝飾模式 使用物件組合的方式，在執行時裝飾類。可以在不修改任何底層 的情況下，給物件賦予新的職責 1.咖啡店例項 問題所在 乙個飲料抽象父類beverage 當子類過多時，出現類的 性複雜 很明顯，這是難以維護的，出現乙個新的飲料就要去繼承父類。一種特例 雙倍奶泡咖啡，算一種飲料，三倍奶泡咖...