C#面向對象設計模式縱橫談第10講：Decorator 裝飾模式

簡體傳統

2006.2.27 李建忠

子類復子類，子類何其多

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

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

動機（Motivation）

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

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

意圖（Intent）

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

——《設計模式》GoF

例說Decorator應用

以前面的例子為例

（糾正：Tank應該也是抽象類）

這里用到了C#對于接口的顯示實現，它在繼承的類里面是個私有的方法，但是在接口中又是公有的。

下面是Decorator模式的實現：

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

（糾正：DecoratorA還應該寫自己的構造器，因為構造器不繼承）

當然，如果不需要對Shot方法或者Run方法進行擴展，可以不override它。

Decorator的結構如下

客戶代碼

可以看到，在Decorator的構造器中，我們除了傳入Tank外，同樣可以傳入Decorator自己作為構造器，這樣裝飾的功能就能夠進行疊加。這也是為什么我們讓Decorator抽象類繼承自Tank抽象類的原因。

因此，如果現在需要加一個功能，我們只需要添加一個功能的裝飾子類就可以了，不需要添加其它的子類。它好就好在擁有運行時的靈活性，可以在需要用時隨意組合功能，而不需要靜態地把各種功能組合寫死在代碼中。

結構（Structure）

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

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

Decorator模式的幾個要點

通過采用組合、而非繼承的手法，Decorator模式實現了在運行時（就是在客戶代碼Main函數里寫的代碼）動態地擴展對象功能的能力，而且可以根據需要擴展多個功能。避免了單獨使用繼承帶來的“靈活性差”和“多子類衍生問題”。

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

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

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

.NET框架中的Decorator應用

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