Decorator(裝飾) — 物件結構型模式

動態地給一個物件新增一些額外的職責。就增加功能來說，Decorator 模式相比生成子類更為靈活。

適用場景

1. 在不影響其他物件的情況下，以動態，透明的方式給單個物件新增職責。
2. 處理那些可以撤銷的職責。
3. 當不能採用生成子類的方法進行擴充時。一種情況是，可能有大量獨立的擴充套件，為支援每一種組合將產生大量的子類，使得子類數目呈爆炸性增長。另一種情況可能類定義被隱藏，或類定義不能用於生成子類。

UML 圖

效果

1. 比靜態繼承更靈活
2. 避免在層次結構高層的類有太多的特徵：Decorator 模式提供了一種“即用即付” 的方法來新增職責。它並不試圖在一個複雜的可定製的類中支援所有可預見的特徵，相反，你可以定義一個簡單的類，並且用 Decorator 類給它逐漸地新增功能。
3. Decorator 與它的 Component 不一樣，Decorator 雖然是一個透明的包裝，但我們從物件標識的觀點出發，一個被裝飾了的元件與這個元件是有差別的，因此，使用裝飾時不應該依賴物件標識。

實現

使用 Decorator 模式時應注意以下幾點：

1. 介面的一致性：裝飾物件的介面必須與它所裝飾的 Component 的介面是一致的，所有的 ConcreteDecorator類必須有一個公共的父類。(至少在C++中如此)
2. 保持 Component 類的簡單性：為了保證介面的一致性，元件和裝飾必須有一個公共的 Component 父類。因此保持這個類的簡單性是很重要的，即它應集中於定義介面而不是儲存資料。對資料表示的定義應延遲到子類中，否則 Component 類會變得過於複雜和龐大，因而難以大量使用。
3. 改變物件外殼與改變物件核心：Decorator可以看做是一個物件的外殼，它可以改變這個物件的行為。另一種方法是改變物件的核心，即 Strategy 模式。
   當 Component 類原本就很龐大時，使用 Decorator 模式代價太高，Strategy 模式相對好一些。在 Strategy 模式中，元件將它的一些行為轉發給一個獨立的策略物件，我們可以替換策略物件，從而改變或擴充元件的功能。

實現略。