先簡單介紹Decorator 模式（裝飾模式）的內容和應用場景。
裝飾模式可以動態地給一個對象添加額外的職責。雖然，利用子類繼承也可以實現這樣的功能，但是 裝飾模式提供了一個更靈活的方式。
因為繼承會為類型引入的靜態特質，使得這種擴展方式缺乏靈活性；
並且隨著子類的增多（擴展功能的增多），各種子類的組合（擴展功能的組合）會導致更多子類的膨 脹。
下面是標准Decorator 模式的UML結構圖：
[此圖來自GOF 《設計模式》一書]
現在結合我實際開發的一個例子談談這個模式的重構應用。
還是那個SEO的項目，涉及群登錄、群發帖、群回復等功能。為了客戶調用簡單和代碼重用，
設計的時候使用三個類來封裝這些功能：SiteLogin、SitePost、SiteReply。每個站點的登錄發帖回 復功能都是調用這三個類實現的。
剛開始設計時，只考慮一般HTTP協議的GET、POST請求，因為剛開始預研的時候，發現幾個網站都是這 樣處理登錄發帖回復的。
隨著後來，網站對象的不斷增加，發現有下面的兩個新需求：
1. 有些站點采用Content-Type為multipart/form-data的方式提交，而不是默認的application/x- www-form-urlencoded方式。
這兩種方式，在httpclient 3.1 中處理方法是完全不同的（雖然4.0版本已經合並到一起了）。
2. 有些站點是采用https的方式提交的（增加額外的功能）。
3. 有些網站是這兩種擴展需求都存在。
當然，為了應付這樣的變數，處理方法有很多，可以在代碼中直接使用if語句來判斷，也可以通過子 類繼承的方式增強這樣的功能。
使用if語句的方式，處理這樣比較大的需求，是不優雅的。子類繼承的方式，在需求組合時會出現子 類數目爆炸式增長。
通過使用Decorator 模式的重構，可以比較好的處理這類問題。
最後設計的UML圖如下（代碼就不貼出來了）：
