之前我們已經學習完了三個「元件協作」模式，接下來我們將進行「單一職責」模式的學習。
「單一職責」模式：
在軟體元件的設計中，如果責任劃分的不清晰，使用繼承得到的結果往往是隨著需求的變化，子類急劇膨脹，同時充斥著重複的**，這時候的關鍵是劃清責任。
「單一職責」模式的典型模式包括decorator和bridge模式，但是這不意味著其他模式沒有責任問題，只是因為這兩個模式在責任問題上表現得極其突出。
這一篇部落格主要進行decorator（裝飾器）模式的學習。
在某些情況下我們可能會」過度地使用繼承來擴充套件物件的功能「，由於繼承為型別引入的靜態特質(有些**是穩定不變的），使得這種擴充套件方法缺乏靈活性；並且隨著子類的增多（擴充套件功能的增多），各種子類的組合（擴充套件功能的組合）會導致更多子類的膨脹。
如何使「物件功能的擴充套件」能夠根據需要來動態的實現？同時避免「擴充套件功能的增多」帶來的子類膨脹問題？從而使得任何「功能擴充套件變化」所導致的影響降為最低？
用裝飾模式實現遊戲角色「莫莉卡·安斯蘭」的變身。
分析：在《惡魔戰士》中，遊戲角色「莫莉卡·安斯蘭」的原身是乙個可愛少女，但當她變身時，會變成頭頂及背部延伸出蝙蝠狀飛翼的女妖，當然她還可以變為穿著漂亮外衣的少女。這些都可用裝飾模式來實現，在本例項中的「莫莉卡」原身有 setimage(string t) 方法決定其顯示方式，而其 變身「蝙蝠狀女妖」和「著裝少女」可以用 setchanger() 方法來改變其外觀，原身與變身後的效果用 display() 方法來顯示，本例的結構圖如下：
從圖中我們可以看出，changer類就是本例中的裝飾器類。
動態（組合）地給乙個物件增加一些額外的職責。就增加功能而言，decorator模式比生成子類（繼承）更為靈活（消除重複**&減少子類個數）。
通過採用組合而非繼承的手法，decorator模式實現了在執行時動態擴充套件物件功能的能力，而且可以根據需要擴充套件多個功能。避免了使用繼承帶來的「靈活性差」和「多子類衍生問題」。
decorator類在介面上表現為is-a component的繼承關係，即decorator類繼承了component類所具有的介面。但在實現上又表現為has-a component 的組合關係，即decorator類又使用了另外乙個component類。（技巧：當乙個類既繼承和組合了乙個相同的類，那麼這個類大概率的使用了decorator模式。）
decorator模式的目的並非解決「多子類衍生的多繼承」問題，decorator模式應用的要點在於解決「主體類在多個方向上的擴充套件功能」——是為「裝飾」的含義。
設計模式學習之裝飾者模式（Decorator）
作用 假設我們有乙個使用了八個物件的程式，由於需求變更，其中三個物件需要另外乙個屬性。讀者可以為這三個物件建立乙個派生類，在多數情況下，這是乙個完全可以接受的方案。然而，如果這三個物件中的每個物件都要求有不同的屬性，這就意味著要建立三個派生類。更進一步，如果其中乙個類具有其他兩個類中的屬性，可能就要...
23種設計模式之裝飾模式（Decorator）
裝飾模式是一種物件結構型模式，可動態地給乙個物件增加一些額外的職責，就增加物件功能來說，裝飾模式比生成子類實現更為靈活。通過裝飾模式，可以在不影響其他物件的情況下，以動態 透明的方式給單個物件新增職責 當需要動態地給乙個物件增加功能，這些功能可以再動態地被撤銷時可使用裝飾模式 當不能採用生成子類的方...
設計模式攻略 結構型模式之Decorator模式
概要 又是一種比較常見也比較常用的模式。系統模組經常需要進行功能上的擴充套件，比如下面這種形式的結構，當需要擴充套件新function時，通常會通過繼承追加新類來實現功能的擴充套件。但是如果我們不是擴充套件乙個新功能的物件，而只是對 所有現有的每種功能類的處理進行擴充套件時，我們應該怎麼做？deco...