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

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

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

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

1.裝飾模式：對被裝飾的物件增加額外的職責，滿足里氏代換原則（子類可以代替父類）
 

如：杯子生產線，杯子必須可以裝水，在生產線上可以給杯子塗顏色，加杯蓋，但要保證杯子可以裝水。

2.代理模式：對被代理的物件提供訪問控制。
如：客戶訂購商品，可以直接從廠家訂購，也可以從網上商城訂購，網上商城是廠家的代理，從網上商城訂購商品，商城可以對商品進行控制，不交錢不給商品，人不在不給商品，也可以贈送你額外的禮品，代金券。

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

從功能效果上看

　　裝飾模式：在不改變介面的前提下，動態擴充套件物件的功能

　　代理模式：在不改變介面的前提下，控制物件的訪問

　　裝飾模式強調功能擴充套件，比如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類時的情況。