先簡單介紹Decorator 模式（裝飾模式）的內(nèi)容和應(yīng)用場景。
裝飾模式可以動(dòng)態(tài)地給一個(gè)對(duì)象添加額外的職責(zé)。雖然，利用子類繼承也可以實(shí)現(xiàn)這樣的功能，但是裝飾模式提供了一個(gè)更靈活的方式。
因?yàn)槔^承會(huì)為類型引入的靜態(tài)特質(zhì)，使得這種擴(kuò)展方式缺乏靈活性；
并且隨著子類的增多（擴(kuò)展功能的增多），各種子類的組合（擴(kuò)展功能的組合）會(huì)導(dǎo)致更多子類的膨脹。
下面是標(biāo)準(zhǔn)Decorator 模式的UML結(jié)構(gòu)圖：
[此圖來自GOF 《設(shè)計(jì)模式》一書]
現(xiàn)在結(jié)合我實(shí)際開發(fā)的一個(gè)例子談?wù)勥@個(gè)模式的重構(gòu)應(yīng)用。
還是那個(gè)SEO的項(xiàng)目，涉及群登錄、群發(fā)帖、群回復(fù)等功能。為了客戶調(diào)用簡單和代碼重用，
設(shè)計(jì)的時(shí)候使用三個(gè)類來封裝這些功能：SiteLogin、SitePost、SiteReply。每個(gè)站點(diǎn)的登錄發(fā)帖回復(fù)功能都是調(diào)用這三個(gè)類實(shí)現(xiàn)的。
剛開始設(shè)計(jì)時(shí)，只考慮一般HTTP協(xié)議的GET、POST請(qǐng)求，因?yàn)閯傞_始預(yù)研的時(shí)候，發(fā)現(xiàn)幾個(gè)網(wǎng)站都是這樣處理登錄發(fā)帖回復(fù)的。
隨著后來，網(wǎng)站對(duì)象的不斷增加，發(fā)現(xiàn)有下面的兩個(gè)新需求：
1. 有些站點(diǎn)采用Content-Type為multipart/form-data的方式提交，而不是默認(rèn)的application/x-www-form-urlencoded方式。
這兩種方式，在httpclient 3.1 中處理方法是完全不同的（雖然4.0版本已經(jīng)合并到一起了）。
2. 有些站點(diǎn)是采用https的方式提交的（增加額外的功能）。
3. 有些網(wǎng)站是這兩種擴(kuò)展需求都存在。
當(dāng)然，為了應(yīng)付這樣的變數(shù)，處理方法有很多，可以在代碼中直接使用if語句來判斷，也可以通過子類繼承的方式增強(qiáng)這樣的功能。
使用if語句的方式，處理這樣比較大的需求，是不優(yōu)雅的。子類繼承的方式，在需求組合時(shí)會(huì)出現(xiàn)子類數(shù)目爆炸式增長。
通過使用Decorator 模式的重構(gòu)，可以比較好的處理這類問題。
最后設(shè)計(jì)的UML圖如下（代碼就不貼出來了）：
友情提示：本博文章歡迎轉(zhuǎn)載，但請(qǐng)注明出處：
陳新漢