Decorator Pattern
動態地將責任附加到對象上。
若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。
Example: 漢堡點餐系統
裝飾者模式會將類別分為兩類：
分別是 裝飾物件類別 (ConcreteComponent) 與 裝飾者類別 (Decorator) 。
其中裝飾物件與裝飾者會實現相同的接口。
在裝飾物件類別不知道裝飾者的情況下，
我們會在產生對象時，動態地將其一個個裝飾上去。
一般會透過建構函式來包裝先前的裝飾者。
便於理解，裝飾物件即被裝飾者。
優點：
當需要動態reuse寫好的類別方法時，
裝飾者模式提供了用組合取代繼承的解決方案。（一種wrapping的委託技術）
職責切分明確，裝飾者類別僅需完成自己的方法，由客戶端決定執行順序。
缺點：
程式碼複雜度提高。
當方法不依賴執行順序時，無法用裝飾者模式實作。
與其他模式的比較：
[策略模式]：
以卡牌遊戲比喻的話，策略模式是決定要出哪張怪獸卡，
而裝飾者模式則是在原有的怪獸卡上，加上裝備卡。
ʕ •ᴥ•ʔ：裝飾者模式專注在對象上，也就更能客製化需求。
（動態產生對象，而不是子類）