物件導向設計原則「合成
/聚合復用原則」指出：盡量不要使用繼承，要盡量使用合成
/聚合。
如果對系統功能擴充套件有很多種方法，可以直接改原始碼，如果改完之後出現的
bug，排錯起來應該相當困難，因為很不容易清楚到底是直接新加入的**出的錯，還是新加入的**導致原有**發生異常；也可以用繼承，直接繼承原有的類，再子類中增加新的功能，再或者直接寫個全新的類替換原有
(有點瘋狂
)。設計模式中的結構型模式可以將類和物件結合在一起形成更強大的結構，結構模式中的裝飾模式可以在客戶端以透明的方式擴充套件物件的功能，是用以繼承關係實現復用方式的一種替代方案。
裝飾模式的角色有：
1、抽象構件（
component
）角色：乙個抽象介面抽象類，用來規範準備接收附加功能的物件。
2、具體構件（
concrete component
）角色：實際或繼承抽象構件乙個類，它可以接收附加的功能。
3、裝飾（
decorator
）角色：實現或繼承抽象構件，並持有乙個構件物件例項，關定義與抽象構件介面一致的介面。
4、具體裝飾（
concrete decorator
）角色：負責為構件物件附加功能。
如果現在有乙個附件上傳類：
class
uploadattachment //
上傳附件方法
//刪除附件方法
public
bool delfile(fillinfo fillinfo)
} 客戶端呼叫**：
客戶端呼叫**：
這裡是乙個退化了的裝飾模式，uploadattachment類同時具有抽象構件和具體構件的角色，thumbnailhandler同時扮演裝飾角色和抽象角色。上例中在客戶端可以像原來物件呼叫一樣來呼叫裝飾例項的方法。
設計模式 3 裝扮你的類（裝飾模式）
首先看看書上的例子吧！人穿衣服的例子！類圖就不畫了，就是簡單的類結構。如下 include using namespace std class person void weartshirts 如果要新新增一種裝扮，那麼就需要修改person類的結構，這樣就違反了開閉原則那就先做抽象好了，把變化的抽象...
設計模式 3 裝扮你的類（裝飾模式）
首先看看書上的例子吧！人穿衣服的例子！類圖就不畫了，就是簡單的類結構。如下 include using namespace std class person void weartshirts 如果要新新增一種裝扮，那麼就需要修改person類的結構，這樣就違反了開閉原則那就先做抽象好了，把變化的抽象...
使用裝飾器模式做類的增強
我們已經實現了使用者註冊功能，現在想增加日誌記錄功能。具體來講就是在使用者註冊前後，分別輸出一條日誌。我們當然可以修改原有的業務 現在換個角度來問兩個問題 1.團隊開發中，我們很可能根本拿不到源 那又怎麼去增加這個功能呢？2.這次需求是增加日誌，以後再增加其他需求 比如異常處理 是不是仍然要改業務類...