大戰設計模式（第二季）【4】———— 從源碼看裝飾者模式
前言
裝飾者模式在實際中應用也很多，裝飾比繼承要靈活，但是同時裝飾的過多也會導致業務上面看上去難以理解，所以合理的使用很重要。對於裝飾者模式來說還有一個比較重要的點就是抽象，抽象出來的內容很重要，決定了後續裝飾的難度。
裝飾模式基礎：https://www.cnblogs.com/linkstar/p/7637675.html
從BufferedReader來看
我們知道在jdk中有一個Reader和BufferedReader，BufferedReader是一個緩沖的輸入流，每次讀取一部分到緩沖中；操作完緩沖中的這部分數據之後，再從Reader中讀取下一部分的數據。
BufferedReader就是Reader的一個裝飾者
?
?
可以看到，很明顯BufferedReader的構造方法中傳入一個Reader，內部有一個私有的Reader，裝飾之後返回出去。
從spring的TransactionAwareCacheDecorator來看
?
從結構和命名上面已經很明顯看出裝飾者模式了，我們來說說他具體是怎麽用的。
TransactionAwareCacheDecorator是處理spring有事務的時候緩存的類，我們在使用spring的cache註解實現緩存的時候，當出現事務的時候，那麽緩存的同步性就需要做相應的處理了，於是就有了這個裝飾者。
我們可以看到下面的方法中：增加了對事務的支持，在事務提交、回滾的時候分別對Cache的數據進行處理，來實現目的。
?具體細節就不詳細說明了，有興趣的小夥伴可以往下看。這裏主要說明，裝飾者模式在這裏的意義。因為並非所有的方法都會使用事務，有的普通方法就不需要裝飾，有的就需要，所以就使用了裝飾者來完成。
從MyBatis中看裝飾者
上面我們看的spring中有緩存，然後對緩存做了裝飾，那我們同樣就能想到MyBatis中也有緩存，是不是也存在這樣的模式呢？果然也是。
?
看的這裏我們就明白了，MyBatis對Cache的裝飾更多，有各種各樣的裝飾者。
這裏簡單先說一下MyBatis的緩存，默認情況下是沒有開啟緩存的，很多人也可能從來沒用到緩存，如果要開啟緩存需要使用標簽
<cache
flushInterval="60000"
size="512"
readOnly="true"/>
這個配置創建了一個 FIFO 緩存,並每隔 60 秒刷新,存數結果對象或列表的 512 個引用,而且返回的對象被認為是只讀的,因此在不同線程中的調用者之間修改它們會 導致沖突。
其中緩存的策略FIFO就是為什麽有這麽多裝飾者的原因了，不同的裝飾者對應了不同的緩存策略。
?
總結
裝飾者模式的核心就是，裝飾者繼承實現抽象的產品，並在內部私有一個產品，利用構造方法對傳入的產品進行裝飾，返回裝飾後的產品。
作者：LinkinStar
轉載請註明出處
全部分類請看：https://www.cnblogs.com/linkstar/category/1087887.html
大戰設計模式（第二季）【4】———— 從源碼看裝飾者模式