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

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

2006.2.27 李建忠

子類復子類,子類何其多

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

image

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

 

動機(Motivation)

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

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

 

意圖(Intent)

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

——《設計模式》GoF

 

例說Decorator應用

以前面的例子為例

image

(糾正:Tank應該也是抽象類)

image

image

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

下面是Decorator模式的實現:

image

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

image

(糾正:DecoratorA還應該寫自己的構造器,因為構造器不繼承)

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

Decorator的結構如下

image

客戶代碼

image

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

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

 

結構(Structure)

image

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應用

image

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

image

image

BufferedStream

image

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

2010.10.3


MSDN 網絡廣播 李建忠 2013-08-22 08:46:25

[新一篇] C#面向對象設計模式縱橫談 第9講:Composite 組合模式

[舊一篇]  C#面向對象設計模式縱橫談 第11講:Facade 外觀模式
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表