子類(lèi)復子類(lèi)，子類(lèi)何其多

　　假如我們需要為游戲中開(kāi)發(fā)一種坦克，除了各種不同的型號的坦克外，我們還希望在不同場(chǎng)合中為其增加以下一種或多種功能：比如紅外線(xiàn)夜視功能，比如水陸兩棲功能，比如衛星定位功能等等。

　　如果再添加一種功能D，那么需要增加的T50子類(lèi)的數量可想而知，而這只是T50這個(gè)類(lèi)型，如果還有其他T70等類(lèi)型，那么需要新添加的子類(lèi)將不可計數。

　　動(dòng)機（Motivation）

　　上述描述的問(wèn)題根源在于我們“過(guò)度地使用了繼承來(lái)擴展對象的功能”，由于繼承為類(lèi)型引入的靜態(tài)特質(zhì)（所謂靜態(tài)特質(zhì)，就是說(shuō)如果想要某種功能，我們必須在編譯的時(shí)候就要定義這個(gè)類(lèi)，這也是強類(lèi)型語(yǔ)言的特點(diǎn)。靜態(tài)，就是指在編譯的時(shí)候要確定的東西；動(dòng)態(tài)，是指運行時(shí)確定的東西），使得這種擴展方式缺乏靈活性；并且隨著(zhù)子類(lèi)的增多（擴展功能的增多），各種子類(lèi)的組合（擴展功能的組合）會(huì )導致更多子類(lèi)的膨脹（多繼承）。

　　如何使“對象功能的擴展”能夠根據需要來(lái)動(dòng)態(tài)（即運行時(shí)）地實(shí)現？同時(shí)避免“擴展功能的增多”帶來(lái)的子類(lèi)膨脹問(wèn)題？從而使得任何“功能擴展變化”所導致的影響降為最低？

　　意圖（Intent）

　　動(dòng)態(tài)地給一個(gè)對象增加一些額外的職責。就增加功能而言，Decorator模式比生成子類(lèi)更為靈活。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設計模式》GoF

　　例說(shuō)Decorator應用

　　以前面的例子為例

　?。m正：Tank應該也是抽象類(lèi)）

　　這里用到了C#對于接口的顯示實(shí)現，它在繼承的類(lèi)里面是個(gè)私有的方法，但是在接口中又是公有的。下面是Decorator模式的實(shí)現：

　　這里Decorator類(lèi)雖然繼承自Tank，但它實(shí)際上應該是接口繼承，而不是類(lèi)繼承。

　?。m正：DecoratorA還應該寫(xiě)自己的構造器，因為構造器不繼承）當然，如果不需要對Shot方法或者Run方法進(jìn)行擴展，可以不override它。

　　Decorator的結構如下

　　客戶(hù)代碼

　　可以看到，在Decorator的構造器中，我們除了傳入Tank外，同樣可以傳入Decorator自己作為構造器，這樣裝飾的功能就能夠進(jìn)行疊加。這也是為什么我們讓Decorator抽象類(lèi)繼承自Tank抽象類(lèi)的原因。因此，如果現在需要加一個(gè)功能，我們只需要添加一個(gè)功能的裝飾子類(lèi)就可以了，不需要添加其它的子類(lèi)。它好就好在擁有運行時(shí)的靈活性，可以在需要用時(shí)隨意組合功能，而不需要靜態(tài)地把各種功能組合寫(xiě)死在代碼中。

　　結構（Structure）

　　Component對應于Tank抽象類(lèi)或接口；ConcreteComponent是Tank的具體實(shí)體類(lèi)，對應于T50、T75、T90。

　　我們需要注意的是Decorator和Component的關(guān)系，首先是繼承關(guān)系（Is-A關(guān)系，這個(gè)Is-A關(guān)系其實(shí)是接口繼承，而不是類(lèi)繼承），然后是Decorator里有一個(gè)Component的關(guān)系（Has-A關(guān)系）。擁有這兩重關(guān)系的優(yōu)勢就是能夠組合起來(lái)，讓它可以不斷地擴展，把一個(gè)個(gè)裝飾串起來(lái)。

　　Decorator模式的幾個(gè)要點(diǎn)

　　通過(guò)采用組合、而非繼承的手法，Decorator模式實(shí)現了在運行時(shí)（就是在客戶(hù)代碼Main函數里寫(xiě)的代碼）動(dòng)態(tài)地擴展對象功能的能力，而且可以根據需要擴展多個(gè)功能。避免了單獨使用繼承帶來(lái)的“靈活性差”和“多子類(lèi)衍生問(wèn)題”。Component類(lèi)在Decorator模式中充當抽象接口的角色，不應該去實(shí)現具體的行為。而且Decorator類(lèi)對于Component類(lèi)應該透明——換言之Component類(lèi)無(wú)需知道Decorator類(lèi)，Decorator類(lèi)是從外部來(lái)擴展Component類(lèi)的功能。Decorator類(lèi)在接口上表現為Is-A：Component的繼承關(guān)系，即Decorator類(lèi)繼承了Component類(lèi)所具有的接口。但在實(shí)現上有表現為Has-A：Component的組合關(guān)系，即Decorator類(lèi)又使用了另外一個(gè)Component類(lèi)。我們可以使用一個(gè)或者多個(gè)Decorator對象來(lái)“裝飾”一個(gè)Component對象，且裝飾后的對象仍然是一個(gè)Component對象。

　　Decorator模式并非解決“多子類(lèi)衍生的多繼承”問(wèn)題，Decorator模式，應用的要點(diǎn)在于解決“主體類(lèi)在多個(gè)方向上的擴展功能”——是為“裝飾”的含義。

　　.NET框架中的Decorator應用

　　Stream是一個(gè)抽象接口，它在System.IO里面，它其實(shí)就是Component。FileStream、NetworkStream、MemoryStream都是實(shí)體類(lèi)ConcreteComponent。右邊的BufferedStream、CryptoStream是裝飾對象，它們都是繼承了Stream接口的。

　　BufferedStream

　　BufferedStream繼承自Stream，又含有Stream作為屬性。有一點(diǎn)不同的是，BufferedStream這個(gè)具體的裝飾類(lèi)沒(méi)有抽象類(lèi)，直接繼承自抽象主體Stream接口，它讓Decorator抽象類(lèi)退化了，但這點(diǎn)不同并不影響Decorator模式的本質(zhì)。