“HeadFirst設計模式“：裝飾模式-創(chuàng)新互聯(lián)

裝飾模式

成都創(chuàng)新互聯(lián)2013年至今，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都網(wǎng)站制作、做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元山南做網(wǎng)站,已為上家服務,為山南各地企業(yè)和個人服務,聯(lián)系電話:13518219792

   裝飾者模式：動態(tài)地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。

   裝修模式的角色如下：

• 抽象構件角色（Component）：給出一個抽象接口，以規(guī)范準備接收附加責任的對象。

• 具體構件角色（Concrete Component）：定義將要接收附加責任的類。

• 裝飾角色（Decorator）：持有一個構件（Component）對象的引用，并定義一個與抽象構件接口一致的接口。

• 具體裝飾角色（Concrete Decorator）：負責給構件對象“貼上”附加的責任。類圖如下：

   裝修模式的特點：

• 裝飾對象和真實對象有相同的接口。這樣客戶端對象就可以以和真實對象相同的方式和裝飾對象交互。

• 裝飾對象包含一個真實對象的引用（reference）。

• 裝飾對象接收所有來自客戶端的請求，它把這些請求轉發(fā)給真實的對象。

• 裝飾對象可以在轉發(fā)這些請求之前或之后附加一些功能。

• 這樣就確保了在運行時，不用修改給定對象的結構就可以在外部增加附加的功能。

   裝修模式的缺點：

• 裝飾模式會導致設計中出現(xiàn)許多小類，如果過度使用，會使程序變得很復雜。

• 裝飾模式是針對抽象組件（Component）類型編程。但是，如果你要針對具體組件編程時，就應該重新思考你的應用架構，以及裝飾者是否合適。當然也可以改變Component接口，增加新的公開的行為，實現(xiàn)“半透明”的裝飾者模式。在實際項目中要做出較佳選擇。

    

    裝飾模式的使用場景：

• 適合對默認目標實現(xiàn)中的多個接口進行排列組合調度

• 適合對默認目標實現(xiàn)進行選擇性擴展

• 適合對默認目標實現(xiàn)未知或者不易擴展的情況。

   實例1：咖啡店有好幾種咖啡，每一種都是自己的價格，成分等，類圖如下；

   問題的產(chǎn)生：咖啡可以放些糖等調料，調料種類多，新增了N個子類來對應咖啡，價格，調料之間的關系，后期維護有了很大的挑戰(zhàn)，類圖如下：

   解決：我們可以用裝飾模式來解決，最終的類圖如下：

   實例2：擴展JAVA里的I/O，讀取文件里的數(shù)據(jù)，并轉成大寫字母輸出

   分析：JDK里I/O框架用到了適配器模式，類圖如下：

   說明：抽象構建角色（InputStream），裝飾角色（FilterInputStream），具體裝飾（BufferdInputStream等），具體構建角色（FileInputStream等）

   實現(xiàn)：我們看類圖，我們繼承FilterInputStream，覆蓋掉read方法就能滿足這個需求了。

   設計原則：類應該對擴展開放，對修改關閉。

當前名稱：“HeadFirst設計模式“：裝飾模式-創(chuàng)新互聯(lián)
本文來源：http://bm7419.com/article48/cdesep.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、網(wǎng)站收錄、服務器托管、網(wǎng)站設計、網(wǎng)站策劃、標簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)