設計模式之裝飾者模式

此設計模式遵循的設計原則之一：類應該支援擴充套件，而拒絕修改（open-closed principle）

裝飾者模式簡述

裝飾者模式通過組合的方式擴充套件物件的特性，這種方式允許我們在任何時候對物件的功能進行擴充套件甚至是執行時擴充套件，而若我們用繼承來完成對類的擴充套件則只能在編譯階段實現，所以在某些時候裝飾者模式比繼承（inheritance）要更加靈活。

裝飾者模式具有的一些特徵

1，裝飾者（decorator）和被裝飾（擴充套件）的物件有著相同的超類（supertype）。

2，我們可以用多個裝飾者去裝飾乙個物件。

3，我們可以用裝飾過的物件替換**中的原物件，而不會出問題（因為他們有相同的超類）。

4，裝飾者可以在委託（delegate，即呼叫被裝飾的類的成員完成一些工作）被裝飾者的行為完成之前或之後加上他自己的行為。

5，乙個物件能在任何時候被裝飾，甚至是執行時。

裝飾者模式的基本結構

我們來看一張《head first 設計模式》裡的圖

（圖中的英文為書中對這個結構的解釋與說明，下面的解釋並不是對圖中英文的直接翻譯，而是博主自己的稍稍結合書中其他內容的總結）

component:

一般是乙個抽象類（也有可能不是），是一組有著某種用途類的基類，包含著這些類最基本的特性。

concretecomponent

：繼承自component，一般是乙個有實際用途的類，這個類就是我們以後要裝飾的物件。

decorator

：繼承自component，裝飾者需要共同實現的介面（也可以是抽象類），用來保證裝飾者和被裝飾者有共同的超類，並保證每乙個裝飾者都有一些必須具有的性質，如每乙個裝飾者都有乙個例項變數（instance variable）用來儲存某個component型別的類的引用。

concretedecorator

：繼承自decorator，用來裝飾component型別的類（不能裝飾抽象類），為其新增新的特性，可以在委託被裝飾者的行為完成之前或之後的任意時候。

乙個簡單的例項

我們用《head first 設計模式》裡舉的星巴克訂單的例子來說明。

星巴克提供不同種類的咖啡和咖啡的調料，星巴克需要一些類來描述他們並且能計算出任意一種咖啡和任意幾種調料搭配在一起的**，如果我們用繼承為每一種搭配寫乙個類的話，就會變成下面這個樣子。

要在工作中用這種東西，還不如讓我們一起狗帶_(:зゝ∠)_。。。。。

當然我們也可把調料都寫在作為超類beverage裡，但是這樣的話會造成資料的大量冗餘，這是乙個解決辦法，但是還不夠好。

如果套用上面所介紹的裝飾者模式的結構就是下面這個樣子

beverage（飲料類）：相當與component

houseblend、darkroast...（混合咖啡類、礁炒咖啡類...）：相當於concretecomponent

condimentdecorator（調料裝飾者類）：相當於decorator

milk、mocha...（牛奶類、摩卡類...）：相當於concretedecorator

裝飾者模式的特點，乙個concretecomponent可以被任意個concretedecorator裝飾。

結合例項就來解釋，一種咖啡可以和任意種調料搭配。

這樣我們來應對各種點單的搭配的時候只需要在一種咖啡（concretecomponent）加上各種（concretedecorator）就可以完成了，是不是覺得特別方便。

以上**

也就是說裝飾者模式裝飾者和被裝飾者必須有相同的抽象超類，我們通過將被裝飾者類的例項傳入裝飾者類（裝飾者類裡會有構造方法接受傳入的被裝飾者），接下來在裝飾者類完成一系列的操作，最後返回這個裝飾者，此時他就已經被裝飾了。io包裡就大量運用這一特性。