大戰設計模式（第二季）【4】———— 從原始碼看裝飾者模式

我們知道在jdk中有一個Reader和BufferedReader，BufferedReader是一個緩衝的輸入流，每次讀取一部分到緩衝中；操作完緩衝中的這部分資料之後，再從Reader中讀取下一部分的資料。

BufferedReader就是Reader的一個裝飾者





可以看到，很明顯BufferedReader的構造方法中傳入一個Reader，內部有一個私有的Reader，裝飾之後返回出去。



從結構和命名上面已經很明顯看出裝飾者模式了，我們來說說他具體是怎麼用的。

TransactionAwareCacheDecorator是處理spring有事務的時候快取的類，我們在使用spring的cache註解實現快取的時候，當出現事務的時候，那麼快取的同步性就需要做相應的處理了，於是就有了這個裝飾者。

我們可以看到下面的方法中：增加了對事務的支援，在事務提交、回滾的時候分別對Cache的資料進行處理，來實現目的。



具體細節就不詳細說明了，有興趣的小夥伴可以往下看。這裡主要說明，裝飾者模式在這裡的意義。因為並非所有的方法都會使用事務，有的普通方法就不需要裝飾，有的就需要，所以就使用了裝飾者來完成。

上面我們看的spring中有快取，然後對快取做了裝飾，那我們同樣就能想到MyBatis中也有快取，是不是也存在這樣的模式呢？果然也是。



看的這裡我們就明白了，MyBatis對Cache的裝飾更多，有各種各樣的裝飾者。

這裡簡單先說一下MyBatis的快取，預設情況下是沒有開啟快取的，很多人也可能從來沒用到快取，如果要開啟快取需要使用標籤

<cache

eviction="FIFO"

flushInterval="60000"

size="512"

readOnly="true"/>

這個配置建立了一個 FIFO 快取,並每隔 60 秒重新整理,存數結果物件或列表的 512 個引用,而且返回的物件被認為是隻讀的,因此在不同執行緒中的呼叫者之間修改它們會 導致衝突。

其中快取的策略FIFO就是為什麼有這麼多裝飾者的原因了，不同的裝飾者對應了不同的快取策略。