深入淺出裝飾模式

1、深入淺出裝飾模式一、引子裝飾模式？肯定讓你想起又黑又火的家庭裝修來。其實(shí)兩者在道理上還是有很多相像的地方。家庭裝修無非就是要掩蓋住原來實(shí)而不華的墻面，抹上一層華而不實(shí)的涂料，讓生活多一點(diǎn)色彩。而墻還是那堵墻，他的本質(zhì)一點(diǎn)都沒有變，只是多了一層外衣而已。那設(shè)計(jì)模式中的裝飾模式，是什么樣子呢？通常OO程序員會(huì)用繼承的方法來擴(kuò)展類的功能，并進(jìn)而解決所面臨的問題。但繼承的威力最多也只能到編譯時(shí)刻為止，運(yùn)行時(shí)它也無能為力了（這里還沒有說繼承可能帶來的麻煩，我們將在后面見到）。但是能夠在運(yùn)行時(shí)對(duì)類功能進(jìn)行擴(kuò)展那才叫“牛”。且看裝飾模式是如何做到這點(diǎn)的。二、定義和結(jié)構(gòu)裝飾模式（Decorator Patte

2、rn）也叫包裝器模式（Wrapper Pattern）。GoF在設(shè)計(jì)模式一書中給出的定義為：動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。換而言之，裝飾類為子類擴(kuò)展新功能提供了一種靈活的替換機(jī)制，Decorator模式比生成子類更為靈活。這里有一家著名的咖啡店Starbuzz，正在抓狂地更新其訂貨系統(tǒng)，以適應(yīng)不斷增長(zhǎng)的供貨要求。為了是咖啡更好喝，或更符合你的口味，你可以向咖啡店要多種調(diào)味品，如steamed milk、soy、mocha，或巧克力等等（當(dāng)然這都是要付錢的，否則就不會(huì)有我們這里的問題的 J）。Starbuzz咖啡店為了調(diào)味品計(jì)費(fèi)的問題頭都大了，因?yàn)樗鼈兌家獑为?dú)處理才行，請(qǐng)看他們的第一個(gè)設(shè)計(jì)

3、：怎么樣？類爆炸了吧！這是因?yàn)槊糠N咖啡中的cost( ) 方法都要考慮其訂單中的不同的調(diào)味料計(jì)費(fèi)問題。上面的設(shè)計(jì)顯然太蠢了，看看一個(gè)更聰明的OO程序員是如何設(shè)計(jì)的。他將設(shè)計(jì)一些實(shí)例變量，并用繼承超類的方法來追蹤調(diào)味料的情況。然后再添加子類，它們各自對(duì)應(yīng)于菜單上的一種咖啡（或其它飲料）：相關(guān)代碼如下，其中最關(guān)鍵的是cost( )方法的代碼：看起來還不錯(cuò)，一共也只有5個(gè)類，cost( )方法也不算太復(fù)雜。那么這樣的設(shè)計(jì)行嗎？請(qǐng)想想下列問題：l 當(dāng)每種調(diào)料的價(jià)格發(fā)生變化怎么辦？好象問題不大，我們還不必改寫代碼！l 如果要加入新的調(diào)味料該怎么辦？我們不得不增加新方法并修改超類中的cost( )方法！l

4、 咖啡店還可以賣別的飲料。如Ice Tea，調(diào)味料是不適用于它們的，但子類IceTea繼承hasWhip( )這樣的方法仍然是非常合理的。千萬不要忘記分類學(xué)的原則，想想上述設(shè)計(jì)違反了分類學(xué)的哪些原則？l 如果客人想要兩份mocha調(diào)料，該怎么辦？l 如果客人想要三份whip調(diào)料，該怎么辦？l 如果客人想要四份soy調(diào)料，該怎么辦？l 等等其它問題此時(shí)我們可以考慮采用裝飾模式來動(dòng)態(tài)的解決上述問題了。先看看裝飾模式的組成，不必急于解決上面的問題，到了下面自然就明白了！1. 抽象構(gòu)件角色（Component）：定義一個(gè)抽象接口，以規(guī)范準(zhǔn)備接收附加責(zé)任的對(duì)象。2. 具體構(gòu)件角色(Concrete Co

5、mponent)：這是被裝飾器，定義一個(gè)將要被裝飾增加功能的類。3. 裝飾角色(Decorator)：持有一個(gè)構(gòu)件對(duì)象的實(shí)例，并定義了抽象構(gòu)件定義的接口。4. 具體裝飾角色(Concrete Decorator)：負(fù)責(zé)給構(gòu)件添加增加的功能。以下是裝飾模式的類圖：臥室談話Mary：哦，我有點(diǎn)困惑我以為我們不會(huì)在這個(gè)模式中使用繼承，而是更加依賴組合來解決問題。Sue： 你什么意思？Mary：看看這個(gè)類圖。類CondimentDecorator擴(kuò)展了類Beverage。這是繼承，對(duì)嗎？Sue： 對(duì)。我想關(guān)鍵點(diǎn)在于裝飾器必須與被裝飾對(duì)象具有相同的類型。因此我們?cè)谶@里使用了繼承以獲得類型匹配的效果，但我

6、們并不使用繼承來獲得行為。Mary：哦，我知道裝飾器為何需要具有與被包裝組件一致的“接口”了，因?yàn)樗鼈冃枰〈笳?。但相關(guān)的行為從哪里來呢？Sue： 當(dāng)我們將一個(gè)裝飾器與一個(gè)組件組合在一起時(shí)，我們就在增加新的行為。我們不是通過繼承超類，而是通過將對(duì)象組合在一起來獲得新的行為。Mary：好的，因此我們繼承了抽象類Beverage以便具有正確的類型，而不是繼承它的行為。行為是通過與其它裝飾器進(jìn)行組合而加入的。Sue： 非常正確。Mary：喔我知道了，因?yàn)槲覀兪褂昧藢?duì)象組合，我們?cè)谌绾螌⒄{(diào)味品與飲料混合起來的問題上獲得了全面而更多的靈活性。非常順暢。Sue： 是的，如果我們依賴?yán)^承的話，那么我們的行

7、為在編譯時(shí)就被靜態(tài)地確定了。換句話說，我們只能擁有超類給予的，或是我們重載的行為。而通過組合，我們可以將裝飾器任意地進(jìn)行混合和匹配在運(yùn)行時(shí)。Mary：而按我的理解，我們可以在任意時(shí)刻實(shí)現(xiàn)新的裝飾器以增加新的行為。如果我們依賴?yán)^承，當(dāng)我們需要新的行為時(shí)就必須進(jìn)入并修改原有的代碼了。Sue： 完全正確。Mary：我還有一個(gè)問題。如果我們所需要繼承的不過是組件的類型，為什么我們不使用一個(gè)接口，而是使用Beverage這個(gè)抽象類呢？Sue： 好的，請(qǐng)記住，當(dāng)我們得到代碼時(shí)，Starbuzz公司已經(jīng)有了一個(gè)抽象類Beverage。傳統(tǒng)上裝飾器模式確實(shí)會(huì)指定一個(gè)抽象組件，但在Java中，顯然我們可以使用接

8、口。但由于我們總是避免修改已有代碼，因此當(dāng)抽象類能夠很好地工作時(shí)就不需要“改正”它。三、解決方案讓我們考慮一個(gè)咖啡訂貨實(shí)例，客戶需要一份Dark Roast咖啡，并且還要了一份Mocha和Whip調(diào)味品。我們將這樣進(jìn)行工作：現(xiàn)在，我們知道了：l 裝飾器與被裝飾對(duì)象具有相同的父類型（supertype）；l 你可以使用一個(gè)或多個(gè)裝飾器包裝一個(gè)對(duì)象；l 由于裝飾器與被裝飾對(duì)象具有相同的父類型，我們可以分發(fā)被裝飾對(duì)象以替換原始（被包裝的）對(duì)象；l 裝飾器可以在委托給被裝飾對(duì)象之前或之后增加其自身的行為，以完成剩余的工作（The decorator adds its own behavior eith

9、er before and/or after delegating to the object itdecorates to do the rest of the job）。這樣就能夠很容易地?cái)U(kuò)展被包裝類的功能，而且沒有修改被包裝類和它的父類；l 對(duì)象可以在任何時(shí)候被裝飾，因此在運(yùn)行時(shí)可以用裝飾器動(dòng)態(tài)、隨意地裝飾我們的對(duì)象。我們可以看一下具體的程序了：StarbuzzCoffee.java Beverage.javaCondimentDecorator.java DarkRoast.javaSoy.java Decaf.javaEspresso.java HouseBlend.javaMilk

10、.java Whip.java以下并非無聊的問題問題：我對(duì)那些可能用于測(cè)試特定具體組件的代碼有些擔(dān)心就是說，HouseBlend或其它什么東西，喜歡打折扣的話。一旦我將HouseBlend用裝飾器包裹起來的話，那打折扣的行為就不管用了?；卮穑捍_實(shí)如此。如果你的代碼依賴于具體組件的類型，那么裝飾器將破壞那些代碼。只要你寫的代碼只依靠抽象組件類型，那么裝飾器的使用對(duì)于你的代碼而言仍然是透明的。然而，一旦你根據(jù)具體組件來寫代碼，你應(yīng)該對(duì)你的應(yīng)用程序設(shè)計(jì)以及裝飾器的使用進(jìn)行重新的思考。問題：某些客戶的飲料不是很容易在最后出問題嗎？它用其它裝飾器，而沒有用最外層裝飾器包裝上。就象我有一杯DarkRoas

11、t咖啡，加了Mocha、Soy和Whip等調(diào)料，在寫代碼時(shí)很容易在最后用了Soy類的引用，而忘記加上Whip類的引用，那就意味著沒有按順序包括Whip調(diào)料。回答：你當(dāng)然會(huì)爭(zhēng)論說由于必須用裝飾模式管理更多的對(duì)象，因此編碼錯(cuò)誤的幾率增加了，從而導(dǎo)致你設(shè)想中的各種問題。然而，裝飾器通常是用其它模式，如工廠模式或建造模式產(chǎn)生的。一旦你學(xué)習(xí)了如何使用這些模式，你會(huì)發(fā)現(xiàn)具體組件與它的裝飾器的生成是“包裝好”的，并不會(huì)導(dǎo)致這些問題。問題：裝飾器能夠知道裝飾鏈上的其它裝飾器嗎？也就是說，我希望自己的getDescription( )方法打印“Whip，Double Mocha”，而不是打印“Whip，Moch

12、a， Mocha”，可以嗎？那就需要我的最外層裝飾器了解在它包裝之內(nèi)的所有裝飾器?；卮穑貉b飾器的本意是為它們包裹的對(duì)象增加行為。當(dāng)你需要窺探裝飾鏈上的多個(gè)層次時(shí)，你就是把裝飾器推離它的本意了。盡管如此，這種事情是可能的。設(shè)想一個(gè)CondimentPrettyPrint裝飾器，它對(duì)說明做最后的解析，并且能夠?qū)ⅰ癕ocha， Whip，Mocha”打印成“Whip，Double Mocha”。請(qǐng)注意getDescription( )方法可以返回一個(gè)有關(guān)說明的列表，使得這項(xiàng)任務(wù)變得容易些。四、現(xiàn)實(shí)世界中的裝飾模式：Java I/O我們可以仔細(xì)閱讀關(guān)于java.io API的文檔，看看各種裝飾器是如何

13、與各種input流組合在一起的。請(qǐng)看以下兩張圖：以上兩圖說明了FilterInputStream是一個(gè)抽象裝飾器類，而BufferedInputStream和LineNumberInputStream是具體的裝飾器類。爐邊夜話HeadFirst：歡迎裝飾模式。我們聽說你最近有點(diǎn)自己看不起自己？Decorator：是的，我知道全世界將我看作是一種富有魅力的模式，但你知道，就象其他所有人一樣，我也有自己的問題。HeadFirst：你愿意把你的麻煩告訴我們嗎？Decorator：當(dāng)然了。嗯，你知道我有本事增加設(shè)計(jì)的靈活性，這是非常有用的，但我也有不好的一面。你看到，我有時(shí)會(huì)向設(shè)計(jì)增加許多小類，而這導(dǎo)

14、致設(shè)計(jì)對(duì)別人不夠直觀，不好理解。HeadFirst：你能給我們一個(gè)例子嗎？Decorator：就拿Java I/O庫(kù)來說吧。開始的時(shí)候，它對(duì)用戶而言是出了名的不好理解。但如果人們將這些類看做是圍繞著一個(gè)InputStream的一組包裝器，那事情就變得簡(jiǎn)單多了。HeadFirst：那聽起來不算太壞呀。你仍然是一個(gè)偉大的模式，而改進(jìn)不足之處只是一個(gè)公共教育問題，對(duì)嗎？Decorator：我擔(dān)心問題會(huì)更多。我有類型問題：你看，人們有時(shí)將一部分依賴于特定類型的代碼拿過來，然后沒有經(jīng)過好好思考就引入裝飾器。現(xiàn)在，我的一個(gè)偉大之處就是你能經(jīng)常透明地插入裝飾器而客戶決不需要知道它是在和裝飾器打交道。但就象我

15、說的，有些代碼依賴于特定的類型，而當(dāng)你引入裝飾器后，砰！壞事發(fā)生了。HeadFirst：哦，我認(rèn)為每個(gè)人都懂得當(dāng)插入裝飾器時(shí)必須要當(dāng)心，我不認(rèn)為你應(yīng)為了這件事情而感到自卑了。Decorator：我知道，我不必如此。我另外的問題就是，對(duì)于實(shí)例化組件所需要的代碼，引入裝飾器會(huì)增加復(fù)雜性。一旦你有了裝飾器，你就不但需要實(shí)例化組件，還要將它用天知道多少個(gè)裝飾器把它包裝起來。HeadFirst：我會(huì)在下星期訪問工廠和建造者模式我聽說他們對(duì)這個(gè)問題很有幫助。Decorator：那好??；我應(yīng)該和那些家伙好好談?wù)劇eadFirst：好的，我們大家都認(rèn)為你是一個(gè)偉大的模式，能產(chǎn)生靈活的設(shè)計(jì)并遵循了OCP原則，

16、所以請(qǐng)?zhí)痤^來，想開些。Decorator：我會(huì)努力的，謝謝你。五、裝飾模式的不足裝飾模式的不足之處有（不過這些缺點(diǎn)好象也沒有什么了不起 J）：l 有時(shí)裝飾模式需要增加太多的小類，這導(dǎo)致設(shè)計(jì)顯得不夠直接而難于理解（sometimes add a lot of small classes to a design and this occasionally results in a design thats less than straightforward for others to understand）；l 由于裝飾器的插入方式是透明，客戶不可能知道他正在和裝飾器打交道（you can us

17、ually insert decorators transparently and the client never has to know its dealing with a decorator）。六、其它信息對(duì)于面向接口編程，應(yīng)該盡量使客戶程序不知道具體的類型，而應(yīng)該對(duì)一個(gè)接口操作。這樣就要求裝飾角色和具體裝飾角色要滿足Liskov替換原則。像下面這樣：Component c = new ConcreteComponent( );Component c1 = new ConcreteDecorator( c );這種方式被稱為透明式。而在實(shí)際應(yīng)用中，比如java.io中往往因?yàn)橐獙?duì)原有接口做太多的擴(kuò)展而需要公開新的方法（這也是為了重用）。所以往往不能對(duì)客戶程序隱瞞具體的類型。這種方式稱為“半透明式”（java.io包中的類并不是純裝飾模式的范例，它是裝飾模式、適配器模式的混合使用）。關(guān)于該模式的應(yīng)用環(huán)境，GoF書中給出了以下適用情況：1. 在不影響其他對(duì)象的情況下，以動(dòng)態(tài)、透明的方式給單個(gè)對(duì)