本筆記摘抄自:http://www.javashuo.com/article/p-oojsxwfr-gm.html,記錄一下學習過程以備後續查用。html
1、引言設計模式
今天咱們要講結構型設計模式的第三個模式--裝飾模式。當第一次看到這個名稱時想到的是另一個詞語「裝修」,我的觀點談談對「裝修」的理解吧,請你們安全
看清楚如今說是「裝修」而不是「裝飾」。當咱們長大了就要準備結婚(男大當婚女大當嫁嘛),而結婚每每涉及到要買房的事。若是買的是毛坯房,假如想要房框架
子的內飾是大理石風格的,咱們只需在毛坯房的基礎之上用大理石風格的材料裝修就能夠(不須要從新蓋房)。房子裝修好了住了進來很開心,過了段時間,ide
發現房子在冬季比較冷,因而就想給房子增長保暖的功能,此時咱們只需在房子裏面增長採暖系統(南方人使用變頻空調)。又過了一段時間,老是有陌生模塊化
人光顧,因而想給房子增長安防設備,此時咱們能夠在門口及室內加裝監控攝像頭(或者加紅外、門磁等布控)及安裝防盜網。隨着時間的流逝,咱們可能學習
會根據咱們的需求增長相應的功能,而在此期間,咱們的房子都是能夠正常使用的,從這一方面來說,「裝修」和「裝飾」有相似的概念。下面讓咱們看看裝飾模spa
式具體是什麼吧?設計
2、裝飾模式介紹3d
裝飾模式:英文名稱--Decorator Pattern;分類--結構型。
2.一、動機(Motivate)
在房子裝修的過程當中,各類功能能夠相互組合,來增長房子的功用。相似的,若是咱們在軟件系統中,要給某個類型或者對象增長功能,若是使用「繼承」
的方案來寫代碼,就會出現子類暴漲的狀況。好比:IMarbleStyle是大理石風格的接口定義、IKeepWarm是保暖的接口定義、IHouseSecurity是房子安全的接
口定義,就三個接口來講,House是咱們房子,房子要什麼功能就實現什麼接口。若是房子要的是複合功能,接口的不一樣組合就會有不一樣的結果,可是會致使
子類膨脹嚴重,隨着功能的不斷增長,會致使子類指數增加。這個問題的根源在於咱們「過分地使用了繼承來擴展對象的功能」,因爲繼承爲類型引入靜態特質
(所謂靜態特質,就是若是想要某種功能,咱們必須在編譯時就要定義這個類,這也是強類型語言的特色。靜態,就是指在編譯的時候要肯定的東西;動態,
是指運行時肯定的東西),使得這種擴展方式缺少靈活性,而且隨着子類的增多(擴展功能的增多)及子類的組合(擴展功能的組合),會致使更多子類的膨
脹(多繼承)。
如何使「對象功能的擴展」可以根據須要來動態(即運行時)地實現?同時避免「擴展功能的增多」帶來的子類膨脹問題?從而使得任何「功能擴展變化」所致使
的影響降爲最低?
2.二、意圖(Intent)
動態地給一個對象增長一些額外的職責。就增長功能而言,Decorator模式比生成子類更爲靈活。—— 《設計模式》GoF
2.三、結構圖(Structure)
2.四、模式的組成
在裝飾模式中的各個角色有:
1)抽象構件角色(Component):給出一個抽象接口,以規範準備接收附加責任的對象。
2)具體構件角色(Concrete Component):定義一個將要接收附加責任的類。
3)裝飾角色(Decorator):持有一個構件(Component)對象的實例,並實現一個與抽象構件接口一致的接口。
4)具體裝飾角色(Concrete Decorator):負責給構件對象添加上附加的責任。
2.5 、裝飾模式的具體實現
繼續拿房子的例子來講吧:
class Program { /// <summary> /// 該抽象類就是房子抽象接口的定義,該類型就至關因而Component類型,須要裝飾的。 /// </summary> public abstract class House { //房子的裝修方法--該操做至關於Component類型的Operation方法。 public abstract void Renovation(); } /// <summary> /// 該抽象類就是裝飾接口的定義,該類型就至關因而Decorator類型,若是須要具體的功能,能夠子類化該類型。 /// </summary> public abstract class DecorationStrategy : House //關鍵點之二,體現關係爲Is-A,有這個關係,裝飾的類也能夠繼續裝飾了。 { //經過組合方式引用Decorator類型,該類型實施具體功能的增長。 //這是關鍵點之一,包含關係,體現爲Has-A。 protected House _house; //經過構造器注入,初始化平臺實現。 protected DecorationStrategy(House house) { _house = house; } //該方法就至關於Decorator類型的Operation方法。 public override void Renovation() { if (_house != null) { _house.Renovation(); } } } /// <summary> /// 個人房子,至關於ConcreteComponent類型。 /// </summary> public sealed class MyHouse : House { public override void Renovation() { Console.WriteLine("裝修個人房子,好比大理石風格。"); } } /// <summary> /// 增長保暖功能,至關於ConcreteDecoratorA類型。 /// </summary> public sealed class KeepWarmDecorator : DecorationStrategy { public KeepWarmDecorator(House house) : base(house) { } public override void Renovation() { //base.Renovation(); Console.WriteLine("增長保暖功能。"); } } /// <summary> /// 增長安防設備,至關於ConcreteDecoratorB類型。 /// </summary> public sealed class SecurityDecorator : DecorationStrategy { public SecurityDecorator(House house) : base(house) { } public override void Renovation() { //base.Renovation(); Console.WriteLine("增長安防設備。"); } } static void Main(string[] args) { #region 裝飾模式 //須要裝飾的房子 House myHouse = new MyHouse(); myHouse.Renovation(); //增長保暖功能 DecorationStrategy warmHouse = new KeepWarmDecorator(myHouse); warmHouse.Renovation(); //若是房子既要保暖又要安防,繼續裝飾就行。 DecorationStrategy warmAndSecurityHouse = new SecurityDecorator(warmHouse); warmAndSecurityHouse.Renovation(); Console.Read(); #endregion } }
寫了不少備註,你們好好體會一下,裏面有兩個關鍵點,仔細把握。
運行結果以下:
3、裝飾模式的實現要點
1)經過採用組合而非繼承的手法,Decorator模式實現了在運行時動態地擴展對象功能的能力,能夠根據須要擴展多個功能,避免了單獨使用繼承帶來的
「靈活性差」和「多子類衍生問題」。
2)Component類在Decorator模式中充當抽象接口的角色,不該該去實現具體的行爲,並且Decorator類對於Component類應該透明--換言之Component類
無需知道Decorator類,Decorator類是從外部來擴展Component類的功能。
3)Decorator類在接口上表現爲Is-A Component的繼承關係,即Decorator類繼承了Component類所具備的接口,但在實現上又表現爲Has-A Component
的組合關係,即Decorator類又使用了另一個Component類。咱們可使用一個或者多個Decorator對象來「裝飾」一個Component對象,且裝飾後的對象仍然
是一個Component對象。
4)Decorator模式並不是解決「多子類衍生的多繼承」問題,Decorator模式應用的要點在於解決「主體類在多個方向上的擴展功能」--是爲「裝飾」的含義。
3.一、裝飾模式的優勢
1)把抽象接口與其實現解耦。
2)抽象和實現能夠獨立擴展,不會影響到對方。
3)實現細節對客戶透明,對用於隱藏了具體實現細節。
3.二、裝飾模式的缺點
1)增長了系統的複雜度
3.三、在如下狀況下應當使用橋接模式
1)若是一個系統須要在構件的抽象化角色和具體化角色之間添加更多的靈活性,避免在兩個層次之間創建靜態的聯繫。
2)設計要求實現化角色的任何改變不該當影響客戶端,或者實現化角色的改變對客戶端是徹底透明的。
3)須要跨越多個平臺的圖形和窗口系統上。
4)一個類存在兩個獨立變化的維度,且兩個維度都須要進行擴展。
4、.NET中裝飾模式的實現
在Net框架中,有一個類型很明顯使用了「裝飾模式」,這個類型就是Stream。Stream類型是一個抽象接口,它在System.IO命名空間裏面,它其實就是
Component。FileStream、NetworkStream、MemoryStream都是實體類ConcreteComponent。右邊的BufferedStream、CryptoStream是裝飾對象,它們都是
繼承了Stream接口。
Stream就至關於Component,定義裝飾的對象,FileStream就是要裝飾的對象,BufferedStream是裝飾對象。
咱們看看BufferedStream的部分定義:
public sealed class BufferedStream : Stream { private const int _DefaultBufferSize = 4096; private Stream _stream; //…… }
結構很簡單,對比結構圖看吧。
5、總結
這個模式有點像包餃子,ConcreteComponent實際上是餃子餡,Decorator就像餃子皮同樣,包什麼皮就有什麼的樣子,皮和皮也能夠嵌套,固然咱們生活中
的餃子只是包一層皮。其實手機也是一個裝飾模式使用的好例子,早期的手機只有接打電話的功能,而後能夠發短信和彩信,再後能夠拍照了。如今的手機功
能很豐富,其結果也相似裝飾的結果。隨着社會的進步和技術發展,模塊化的手機也出現了,其設計原理愈來愈接近「裝飾模式」。不光是手機,咱們身邊的很
多家用電器也有相似的發展經歷,讓咱們努力發現生活中的真理吧,而後再在軟件環境中慢慢體會。