decorator模式與介面卡模式、包裝器模式有點像。
原有的抽象類absclassitf定義了某種介面itfx。原有的具體類conclass實現了這個介面。原有的介面itfx和其派生的功能實現成員函式都有很好的概念一致性。但是有些特殊的場合、流程下，需要對conclass的itfx實現增加一些額外的功能。如果將這些額外的功能加入到conclass的實現中，一是會使原函式變的臃腫，複雜，破壞原來的概念一致性，僅僅因為一些特殊場合的需求；二是不夠靈活，將來有些場合下，這些後來加入的功能可能又要修改，整個原來的類都需要重新編譯。這違背了開放---封閉原則。
如果定義乙個類decoratorclass，同樣實現itfx介面， 在其實現**中，呼叫了原conclass對itfx的實現，又額外增加一些特殊功能，這樣在客戶**中，呼叫 decoraotrclass的iftx介面就能很好的完成任務。由於 conclass和新的decoratorclass都可以由absclass的指標所指向，所以，decoratorclass可以裝飾另外乙個裝飾類，或者conclass類，非常靈活。
設計模式的教材總結說：如果是動態的為乙個物件增加額外的功能，裝飾模式比生成子類更靈活----關鍵是，有些時候，在沒有is-a關係時，生成子類很容易破壞繼承層次的概念一致性。
#include
#include
using namespace std;
//裝飾模式----動態地為物件增加額外的功能， 特別是對於增加功能來說，裝飾模式比生成子類更靈活！
//首先定義原有功能類----被修飾類---它完全不需要知道修飾類在存在，不必要關心修飾類的處理----它只要關心完成好自己的任務，維護好自己的概念一致性的功能內聚性。例子中只有girl類，可以不定義父類。但是如果要動態增加功能的類不只有girl，還有officelady，那麼定義共同父類就可以更簡化**。
class female
};class girl : public female
string name()
void name(string name)
unsigned int age()
void age(unsigned int age)
void show();
//定義裝飾類，它們指定要裝飾的物件，然後實現和裝飾物件相同的介面show，在實現show時，先呼叫裝飾物件的show，完成原有物件的功能，再加入自己的裝飾性功能----這就是裝飾模式的含義。
class girldecorator : public female
void setdecoratee(female* pdecoratee)
protected:
female* p_decoratee;
};class wareflower : public girldecorator
;class eatbreakfast : public girldecorator
設計模式學習 Decorator 裝飾
意圖 動態的為乙個物件新增一些額外的職責,decorator比子類更加靈活 示例圖 適用性 在不影響物件的情況下，以動態,透明的方式給單個物件新增職責 處理那些可以撤銷的職責 但不能使用子類進行擴充時 類被隱藏 類定義不能生成子類 注意事項 裝飾物件的介面必須與它所裝飾的component的介面一致...
設計模式學習（四） Decorator
之前我們已經學習完了三個 元件協作 模式，接下來我們將進行 單一職責 模式的學習。單一職責 模式 在軟體元件的設計中，如果責任劃分的不清晰，使用繼承得到的結果往往是隨著需求的變化，子類急劇膨脹，同時充斥著重複的 這時候的關鍵是劃清責任。單一職責 模式的典型模式包括decorator和bridge模式...
設計模式 decorator模式
裝飾者模式體現了 敏捷開發思想中的 對類要 開放擴充套件,關閉修改.例子 乙個person主類 若干裝飾品類 紅衣服,藍衣服,藍鞋子,紅鞋子 測試 new乙個person 給他穿上紅衣服藍鞋子 code person介面 public inte ce ipersonperson類 package c...