java設計模式之裝飾模式代理模式差別

初次看裝飾模式的時候首先想到了上節講的代理模式，代理模式與裝飾者模式看起來很像，都實作基礎對象實作的接口，在其自身對象中都儲存着對被代理/被裝飾者的對象引用。      

各用一句話描述兩個模式應該是這樣的：      

裝飾模式：以對用戶端透明的方式擴充對象的功能，是繼承關系的一個替代方案， Java IO的設計即是裝飾者模式。
代理模式：給一個對象提供一個代理對象，并有代理對象來控制對原有對象的引用，spring的動态代理即使用的代理模式。

從描述中可以看出來兩者的差別：裝飾模式應該為所裝飾的對象增強功能；代理模式對代理的對象施加控制，并不提供對象本身的增強功能。 舉個例子：      

還看到一篇文章從以下兩方面進行的分析，也拿來參考一下：      

從功能效果上看      

　　裝飾模式：在不改變接口的前提下，動态擴充對象的功能

　　代理模式：在不改變接口的前提下，控制對象的通路

　　裝飾模式強調功能擴充，比如A對象的B方法，運用裝飾模式後，在調用B方法前後，實作新的功能，此時B方法效果與原來不同

　　代理模式強調控制通路，如上例，運用代理模式後，在調用B方法前後，控制怎麼通路B方法的原始資料，而對于B實作的功能效果不做修改

　　是以，如果運用設計模式後，方法的功能效果（主要是輸出效果）不變，一般可視為代理。

　　

	從類結構上看

　　通過裝飾模式結構圖中可以看出

　　
        
  
               


　　Component類在Decorator模式中充當抽象接口的角色，不應該去實作具體的行為。而且Decorator類對于Component類應該透明，換言之Component類無需知道Decorator類，Decorator類是從外部來擴充Component類的功能。

　　Decorator類在接口上表現為is-a Component的繼承關系，即Decorator類繼承了Component類所具有的接口。但在實作上又表現為has-a Component的組合關系

　　Decorator模式在實際中的運用可以很靈活。如果隻有一個ConcreteComponent類而沒有抽象的Component類，那麼Decorator類可以是ConcreteComponent的一個子類。

　　同樣，通過代理模式結構圖中可以得出

　　
        
  
             


　　代理類和被代理對象是has-a關系，一般沒有is-a關系，除非代理類直接繼承被代理類，重寫被代理類的方法，即上圖中沒有抽象Subject類時的情況。