為什么80%的碼農都做不了架構師？>>> ??

終于有時間寫點什么了，可以前醞釀好的東西似乎一下子都忘記了。這幾天看了wayfarer的《《讓僵冷的翅膀飛起來》系列之三——從Adapter模式到Decorator模式》 后，感覺這樣的文章真應當多發一些，激發思路。只是本來想用高級評論，卻發現默認高級評論使用的是CuteEditor，在我的機器上根本無法使用，鼠標 始終是沙漏（不知道是不是跟防火墻有關），而自己又無法選擇使用什么編輯器編輯高級評論，所以才不得不寫篇文章說說我的想法，看來又要有勞dudu了。

當 初提出使用Decorator模式的是我，可現在提出異議的又是我，不要說我胡攪蠻纏，討論中才能增長經驗呀。wayfarer與idior的評論對我有 很大啟發，但我發現現在似乎有些問題沒有定義清楚，導致在探討解決辦法時模棱兩可。第一，原有設計是否不允許有任何變動。wayfarer的文章中，似乎 默認是不允許對原有系統進行任何修改，而是通過增加新代碼的方式提供新功能。否則以下的設計就應當能夠解決問題了：

第 二，新增加的Resize方法是否與RM或MPEG的具體實現糾纏不清。如果Resize的實現相對獨立，只要針對抽象VideoMedia中的方法和屬 性就可以完成所有功能，那么使用Decorator模式無疑是個不錯的選擇，丑陋的"if (!(vedio is RM))"也可以不用出現在代碼當中（具體可以參考wayfarer的原文）。設計如下：

因為SizeDecorator中的Resize方法只針對VideoMedia中的抽象方法執行操作，所以系統也就沒有必要判斷VideoMedia具體是RM還是MPEG，多態性自動替我們解決了這個問題。

但 是，正如wayfarer和idior所說的，Decorator并不適合為一個對象添加新功能。否則當對一個VideoMedia應用多個 Decorator時，從類型上講用戶只能看到最后一次Decorate時加入的新功能，以前的Decorator所起的作用被"屏蔽"了。

除 此之外，如果Resize方法依賴于具體的VideoMedia類型，那恐怕帶來的就是災難了。因為在編寫Resize方法時，必須清楚的知道你是對RM 操作還是對MPEG操作，VideoMedia類型的_video也就形同虛設，丑陋的"if (!(vedio is RM))"也必不可免了。在這種情況下，還不如使用"類適配器模式"好（可以參考《《《讓僵冷的翅膀飛起來》系列之二——從實例談Adapter模式）。

第 三，Visitor模式是否可行？其實，如果將條件限定為不允許改變任何原有代碼的化，Visitor模式根本沒有用武之地。因為Visitor模式象踢 皮球一樣需要一個"回傳"功能，才能針對具體類型具體操作。可添加"回傳（允許被Visit）"功能必須修改VideoMedia、RM與MPEG，這樣 就違反了規則。

所以，我們應將盡量"針對抽象編程"。這樣可以防止Resize方法過分依賴于具體。否則，不管使用哪種模式，都會"犧 牲"大量的代碼。除此之外，當我們必須了解類型信息時，同時又要保證類型匹配（RMDecorator只能裝飾RM）時，可以考慮使用抽象工廠（取其 意），將RMDecorator、與RM認為是一個產品族。

另外，如果需要動態為現有對象添加多個方法時，是否可以考慮使用 DynamicProxy，借助Mixin機制為一個類動態添加行為。但是我剛剛開始學習DynamicProxy、AOP和Mixin，感覺在需要我們 了解具體類型后再進行操作的場合下，這些機制似乎幫不了什么太大的忙。如果有這方面的高手，還望指點一二。

?

轉載于:https://my.oschina.net/qihh/blog/57825

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的也说说“从Adapter模式到Decorator模式”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。