前言

在實際開發時，你有沒有碰到過這種問題；開發一個類，封裝了一個對象的核心操作，而這些操作就是客戶使用該類時都會去調用的操作；而有一些非核心的操作，可能會使用，也可能不會使用；現在該怎么辦呢？

1.將這些非核心的操作全部放到類中，這樣，一個類就包含了很多核心的操作和一些看似有關，但是又無關的操作；這就會使核心類發生“爆炸”的現象，從而使核心類失去了一定的價值，也使使用核心類的客戶在核心操作和非核心操作中掙扎；

2.使用繼承來擴展核心類，需要使用核心類時，直接建立核心類對象；當需要使用核心類擴展類時，就建立核心類擴展類對象；這樣貌似是一種很有效的方法；但是由于繼承為類型引入的靜態特質，使得這種擴展方式缺乏靈活性；同時，又掉入了另一個陷阱，隨著擴展功能的增多，子類也會增多，各種子類的組合，就會導致類的膨脹，最后，就會被淹沒在類的海洋；此時，也不用我多說，你是不是想起了橋接模式，橋接模式就是為了適應多個維度的變化而發生子類“爆炸”的情況，但是，橋接模式是為了適應抽象和實現的不同變化，并不適用于我這里說的。那如何是好，這就要說到今天總結的裝飾模式了。

什么是裝飾模式？

在GOF的《設計模式:可復用面向對象軟件的基礎》一書中對裝飾模式是這樣說的：動態地給一個對象添加一些額外的職責。就增加功能來說，Decorator模式相比生成子類更為靈活。

裝飾模式能夠實現動態的為對象添加功能，是從一個對象外部來給對象添加功能。通常給對象添加功能，要么直接修改對象添加相應的功能，要么派生對應的子類來擴展，抑或是使用對象組合的方式。顯然，直接修改對應的類這種方式并不可取。在面向對象的設計中，而我們也應該盡量使用對象組合，而不是對象繼承來擴展和復用功能。裝飾器模式就是基于對象組合的方式，可以很靈活的給對象添加所需要的功能。裝飾器模式的本質就是動態組合。動態是手段，組合才是目的?？傊?，裝飾模式是通過把復雜的功能簡單化，分散化，然后再運行期間，根據需要來動態組合的這樣一個模式。它使得我們可以給某個對象而不是整個類添加一些功能。

UML類圖

Component:定義一個對象接口，可以給這些對象動態地添加職責；

ConcreteComponent:定義一個具體的Component，繼承自ConcreateComponent，重寫了Component類的虛函數；

Decorator:維持一個指向Component對象的指針，該指針指向需要被裝飾的對象；并定義一個與Component接口一致的接口；

ConcreteDecorator:向組件添加職責。

代碼實現：

使用場合

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

注意事項

1.接口的一致性；裝飾對象的接口必須與它所裝飾的Component的接口是一致的，因此，所有的ConcreteDecorator類必須有一個公共的父類；這樣對于用戶來說，就是統一的接口；

2.省略抽象的Decorator類；當僅需要添加一個職責時，沒有必要定義抽象Decorator類。因為我們常常要處理，現存的類層次結構而不是設計一個新系統，這時可以把Decorator向Component轉發請求的職責合并到ConcreteDecorator中；

3.保持Component類的簡單性；為了保證接口的一致性，組件和裝飾必須要有一個公共的Component類，所以保持這個Component類的簡單性是非常重要的，所以，這個Component類應該集中于定義接口而不是存儲數據。對數據表示的定義應延遲到子類中，否則Component類會變得過于復雜和臃腫，因而難以大量使用。賦予Component類太多的功能，也使得具體的子類有一些它們它們不需要的功能大大增大；

實現要點

1.Component類在Decorator模式中充當抽象接口的角色，不應該去實現具體的行為。而且Decorator類對于Component類應該透明，換言之Component類無需知道Decorator類，Decorator類是從外部來擴展Component類的功能；

2.Decorator類在接口上表現為“is-a”Component的繼承關系，即Decorator類繼承了Component類所具有的接口。但在實現上又表現為“has-a”Component的組合關系，即Decorator類又使用了另外一個Component類。我們可以使用一個或者多個Decorator對象來“裝飾”一個Component對象，且裝飾后的對象仍然是一個Component對象；

3.Decortor模式并非解決“多子類衍生的多繼承”問題，Decorator模式的應用要點在于解決“主體類在多個方向上的擴展功能”——是為“裝飾”的含義；

4.對于Decorator模式在實際中的運用可以很靈活。如果只有一個ConcreteComponent類而沒有抽象的Component類，那么Decorator類可以是ConcreteComponent的一個子類。如果只有一個ConcreteDecorator類，那么就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合并成一個類。

5.Decorator模式的優點是提供了比繼承更加靈活的擴展，通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合；

6.由于使用裝飾模式，可以比使用繼承關系需要較少數目的類。使用較少的類，當然使設計比較易于進行。但是，在另一方面，使用裝飾模式會產生比使用繼承關系更多的對象。更多的對象會使得查錯變得困難，特別是這些對象看上去都很相像。

與橋接模式的區別

之前總結了C++設計模式——橋接模式；你會發現，二者都是為了防止過度的繼承，從而造成子類泛濫的情況。那么二者之間的主要區別是什么呢？橋接模式的定義是將抽象化與實現化分離（用組合的方式而不是繼承的方式），使得兩者可以獨立變化?？梢詼p少派生類的增長。如果光從這一點來看的話，和裝飾者差不多，但兩者還是有一些比較重要的區別：

1.橋接模式中所說的分離，其實是指將結構與實現分離（當結構和實現有可能發生變化時）或屬性與基于屬性的行為進行分離；而裝飾者只是對基于屬性的行為進行封閉成獨立的類，從而達到對其進行裝飾，也就是擴展。比如：異常類和異常處理類之間就可以使用橋接模式來實現完成，而不能使用裝飾模式來進行設計；如果對于異常的處理需要進行擴展時，我們又可以對異常處理類添加Decorator，從而添加處理的裝飾，達到異常處理的擴展，這就是一個橋接模式與裝飾模式的搭配；

2.橋接中的行為是橫向的行為，行為彼此之間無關聯，注意這里的行為之間是沒有關聯的，就比如異常和異常處理之間是沒有行為關聯的一樣；而裝飾者模式中的行為具有可疊加性，其表現出來的結果是一個整體，一個各個行為組合后的一個結果。

總結

裝飾模式重點在裝飾，對核心功能的裝飾作用；將繼承中對子類的擴展轉化為功能類的組合，從而將需要對子類的擴展轉嫁給用戶去進行調用組合，用戶如何組合由用戶去決定。我在學習裝飾模式時，就是重點分析了“裝飾”這個詞，我們都知道，裝飾是在一個核心功能上添加一些附屬功能，從而讓核心功能發揮更大的作用，但是最終它的核心功能是不能丟失的。這就好比我們進行windows shell開發時，我們是對windows的這層殼進行了功能的裝飾，從而實現了我們需要的一些裝飾功能，但是最終的功能還是由windows shell去完成。這就好比，我們的裝飾就是給核心功能添加了一層外衣，讓它看起來更漂亮和完美。