無用的設計模式之裝飾者模式

前言

      裝飾者設計模式原本是很經常使用的模式，經常使用到隨處可見，jdk的bio設計都是遵循這個模式的，偶然的機會發現，貌似jdk中bio的裝飾者模式和設計模式中的裝飾者設計模式卻有點本質上的不一樣，可是仔細想一想，貌似bio的設計貌似還有點違背設計模式的本意，此文中把裝飾者模式說成無用，是由於他定義的這種規範的玩法，你們貌似並不聽從，反而更喜歡jdk中的用法。

---

類圖

        這個類圖你們也並不陌生，具體的被裝飾的類和裝飾者都是遵循同一個規範，component，此處若是component沒有公共的定義方法，那就是妥妥的面向接口編程。看這個用法咱們也能猜到怎麼用，先建立被裝飾的類，而後用裝飾類去修飾被裝飾的類，而後把引用給component，調用operation的時候就把裝飾的效果顯示出來，若是需求變動，那麼直接把裝飾組合出來的過程改改，其餘代碼不須要改變。

---

jdk bio的用法

         做爲裝飾者模式的典型，他的類圖徹底和上面的類圖吻合，可是咱們的用法卻大大不一樣，咱們包裝後的IO類，咱們不多直接讓接口來做爲引用，每個裝飾類都帶了本身的新特性，API都不同了。咱們想要用包裝類的功能就必須使用包裝類的引用，不然就切面了，咱們能用到的只有接口的方法。他的側重是不一樣的包裝是不一樣的功能，相似readline,只有bufferedreader有，咱們想用只能依靠這個包裝類，可是類自己也遵循接口，因此也能傳遞給接口，可是要損失包裝的特性。

---

兩種用法的對比

        單純從軟件設計講，jdk io的設計擴展性很差，由於你選擇包裝，原本就是但願調用統一的方法，這樣對代碼的修改最小。但現實是咱們若是不用具體的類沒法增長新的功能。也就是說你想體現新的功能的話，後面的代碼基本要重寫。你們公有的那部分方法壓根沒有加強到，這樣寫確定會帶來不小的隱患，但很特殊的是，他設計的是IO，通常讀取完就over,有傳遞的可能性，可是用接口傳過去後從新包裝一下又可使用了，反正是各自包裝各自的，公有的方法都不用，這樣下來反而也沒什麼影響。要選擇這麼使用的話必定得慎重，用很差就帶來不少麻煩。

---

適合場景

        一看類圖，你們基本就能感受這個更像補救型的模式，就是原來的類都實現好了，如今忽然要改需求，給裏面的部分類的方法都增長一種或者多種功能，這樣裝飾者模式就派上用場了，直接在建造對象的地方加一段裝飾，固然這個前提都是被裝飾的類和裝飾的類都是能夠估計的，遇到不可估計的狀況仍是直接用aop動態代理吧，不要再考慮裝飾模式。既然是補救行的，那麼也是有必定要求的。

        起碼最初的類圖是這樣的，要否則還要添加接口等等（這個確定是不可取的），POJO的話仍是用動態代理的好。

        另一種適合狀況就是多繼承，要對中間繼承類須要增長，這種狀況用裝飾者模式不會影響子類的功能。

---

和靜態代理的區別

       其實文中屢次提到代理，其實在功能單一的狀況下，代理和裝飾均可以，我最後想一想仍是從功能上作點區別，裝飾者適合新增的功能能夠互相組合的狀況，及裝飾類和裝飾類是能夠疊加操做的，而且被裝飾的方法仍是較少的，裝飾的類的個數也是較少的。靜態代理更適合類中方法不少，可是隻會代理一層，出現多層代理基本就是不合理的，典型的就是datasource中用本身的connection類代理jdbc中的connection類。

---

最後說幾句

       其實用裝飾者模式帶來種種功能上的好處，可是一旦出現問題，你本身寫的代碼還好，要是讓純粹不知道的人走斷點找問題，那跟斷點可就費事了，因此必定留好設計文檔和把類的名字起的見字生義。