前言：本篇系看完《研磨設計模式》一書的個人理解和總結，可能存在不正確的地方，看時需要持懷疑態度。另外，所有的圖都是示意圖，示意，示。
裝飾器模式（Decorator）：
幾點解釋：
- 裝飾器模式的本質在於，透明的給對象增加新的功能，並且這些功能可以靈活的組合和增減。
- 如果沒有了那個抽象類，其實就和代理模式的結構是一致的了，二者的區別已經在前面代理模式說過了。
- 裝飾對象會持有一個實際的對象或者是已經被裝飾之後的對象，因爲大家都是實現了同一個接口。通過層層嵌套的方式，給實際的對象增加很多新的功能。
- 實際使用時，需要在客戶端先創建實際的對象，之後將其傳入一個裝飾對象中，之後還可以將裝飾對象再傳入裝飾對象之中。實際調用時，是向最外層的裝飾對象發起調用，之後的過程有點類似於遞歸調用。
- Java中的IO庫，使用的就是裝飾器模式，各種的 InputStream 可以靈活的嵌套使用。
職責鏈模式（Chain of Responsibility）：
幾點解釋：
- 職責鏈模式的本質在於 將各種不同的職責分離並封裝，使得在使用時可以動態組合。
- 一個請求過來，會有多個對象都有機會處理，此時將這些對象組裝成鏈（內鏈、外鏈），只需要將請求發送給第一個對象，這個請求就會在職責鏈中傳遞，標準的職責鏈有一個對象處理了就會返回。
- 如果將職責鏈進行變形，不是有一個處理就返回，而是每個對象都會做出一些處理，處理完成後將請求傳遞給下一個對象，此時就變成了一條功能鏈。職責鏈變形成功能鏈之後，其實和裝飾模式很像了，裝飾模式也是一條鏈。不同點在於：裝飾模式大多相互依賴，這個裝飾對象一般會依賴上一個裝飾對象返回的結果，並在此基礎上進行進一步操作，而職責鏈模式一般相互獨立，各處理各的，處理完只是簡單的將請求轉發給下一個對象。
- 鏈的形成可以是內鏈，即 一個對象持有下一個對象的引用，依次調用，也可以用有序容器將這些對象組裝爲外鏈，由外部統一調用。