子類復(fù)子類，子類何其多

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

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

　　動機（Motivation）

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

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

　　意圖（Intent）

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設(shè)計模式》GoF

　　例說Decorator應(yīng)用

　　以前面的例子為例

　　（糾正：Tank應(yīng)該也是抽象類）

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

　　這里Decorator類雖然繼承自Tank，但它實際上應(yīng)該是接口繼承，而不是類繼承。

　　（糾正：DecoratorA還應(yīng)該寫自己的構(gòu)造器，因為構(gòu)造器不繼承）當然，如果不需要對Shot方法或者Run方法進行擴展，可以不override它。

　　Decorator的結(jié)構(gòu)如下

　　客戶代碼

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

　　結(jié)構(gòu)（Structure）

　　Component對應(yīng)于Tank抽象類或接口；ConcreteComponent是Tank的具體實體類，對應(yīng)于T50、T75、T90。

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

　　Decorator模式的幾個要點

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

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

　　.NET框架中的Decorator應(yīng)用

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

　　BufferedStream

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

it知識庫：C#面向?qū)ο笤O(shè)計模式縱橫談：Decorator 裝飾模式，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。