我們在軟體開發中可能想給物件新增個附加功能,但是又不想去破壞此物件的結構。舉個栗子,比如說你平常玩王者榮耀的普通模式,突然有一天,老闆要你開發個末日模式,
但是這個活動只開1個星期,你是改原有基礎好呢,還是不改原有基礎好呢。
定義乙個抽象
///
/// 遊戲角色
///
public abstract class playrole
}
public override void
generalattack()
抽象構件（phone）角色：給出乙個抽象介面，以規範準備接受附加責任的物件。
裝飾（dicorator）角色：持有乙個構件（component）物件的例項，並定義乙個與抽象構件介面一致的介面。
具體裝飾（sticker和accessories）角色：負責給構件物件 」貼上「附加的責任。
和繼承實現的功能都是一樣(擴充套件功能)
把縱向繼承變成了橫向擴充套件(減少了子類**的情況)
擴充套件性更高 可以隨機組合你要的擴充套件功能
裝飾器模式閱讀性比較差
裝飾者模式（結構型）
裝飾者模式 動態的將責任附加到物件上。若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。裝飾者模式類圖 component是我們要裝飾的元件，decorator是我們的裝飾器，在這裡繼承要裝飾的元件 使用裝飾的目的就是拓展功能而不改變原有的 這樣，我們新增乙個裝飾者，客戶端依然可以呼叫原有的元...
裝飾者模式 結構型
裝飾器模式 動態地給乙個物件新增一些額外的職責或者行為。就增加功能來說，decorator模式相比生成子類更為靈活。裝飾器模式提供了改變子類的靈活方案。裝飾器模式在不必改變原類檔案和使用繼承的情況下，動態的擴充套件乙個物件的功能。它是通過建立乙個包裝物件，也就是裝飾來包裹真實的物件。在裝飾模式中的角...
裝飾模式（結構型模式）
裝飾模式是一種動態的給類中新增新行為的設計模式，裝飾模式比生成子類更為靈活，可以給某個物件而不是整個類新增一些功能。值得注意的是裝飾模式的裝飾類也繼承介面類，同時他也有介面類的指標指向他需要裝飾的具體類。外表看著像is a的關係，實際也是has a的關係。實際應用中裝飾類可以同時裝飾幾個具體類。可以...