上篇文章提到了Context及其子類源碼分析（一），這篇文章我們來講講Context及其子類用到的設計思想——裝飾者模式魔慷。
（一）裝飾者模式UML
Component抽象構件角色：真實對象和裝飾對象有相同的接口抡句。這樣膀息，客戶端對象就能夠以與真實對象相同的方式同裝飾對象交互旧噪。相當于Context尖坤。
ConcreteCompoent具體構建角色(真實對象)：定義一個將要接收附加責任的類囱持。相當于ContextImpl夯接。
Decorator裝飾角色：持有一個抽象構件的引用，用set方法將真實對象塞入Decorator裝飾角色中纷妆。裝飾對象接受所有客戶端的請求盔几，并把這些請求轉發(fā)給真實的對象。這樣掩幢，就能在真實對象調用前后增加新的功能逊拍。相當于ContextWrapper。
ConcreteDecorate具體裝飾角色：負責給構件對象增加新的功能际邻。相當于ContextThemeWrapper芯丧、Activity袭灯、Service和Application至非。
大家可以去看上一篇文章：Context及其子類源碼分析或者自己打開源碼查看钝计，Context及其子類就是活脫脫的裝飾者模式。
（二）為什么用裝飾者模式
看了很多關于為什么要用裝飾者模式的博客翁潘，但是都沒真正明白為裝飾者模式的應用場景剥哑，只記得別人一直強調裝飾者模式可以在不修改原類的代碼的情況下师枣，進行功能擴展霞篡。
（1）直到我想到代理模式好似也有擴展功能的作用，那么萧锉，二者有什么區(qū)別呢珊随？
我找到了這篇文章——設計模式：代理模式與裝飾模式。里面有代碼例子柿隙，寫的特別詳細叶洞。大家一定要看看，如果你覺得看的亂的話禀崖，那一定是因為你對兩種模式的代碼不熟悉衩辟，怎么辦？把代碼背下來胺馈惭婿！靜下心不要浮躁，反正我是看了很多遍很多遍兩種模式的代碼叶雹。然后對比類中有什么變量、實現(xiàn)了什么接口换吧、到底繼承自哪個類折晦、客戶端怎么調用調用。
簡而言之沾瓦，裝飾者模式的ConcreteCompoent具體構建角色和Decorator裝飾角色都繼承自抽象類Component抽象構件角色满着，Decorator裝飾角色中有ConcreteCompoent具體構建角色的引用，客戶端調用時候贯莺，會出現(xiàn)ConcreteCompoent具體構建角色的類风喇。
而靜態(tài)代理模式的代理類和被代理類同樣是實現(xiàn)了同一個接口或繼承自同一個類。區(qū)別是缕探，代理類中實例了被代理對象魂莫，即代理類和被代理類是組合關系。而客戶端調用的時候爹耗，并不需要實例被代理類耙考。
當然了，代理類在調用被代理的方法時候可以適當?shù)脑黾右恍┕δ芴妒蓿鳛楣δ軘U展倦始。但是相對的，裝飾模式主要是強調對類中代碼的拓展山卦，而代理模式則偏向于委托類的訪問限制鞋邑。兩者的出發(fā)點是不一樣的。因為客戶端并不需要知道你到底代理了哪個類，我直接調用代理類的方法枚碗，而代理類內部怎么調用被代理類藻懒，我客戶端不關心。這就是所謂的偏向于為委托類的訪問限制视译。
（2）繼承也可以擴展父類功能嬉荆，那為什么還要用裝飾者模式呢？
其實裝飾者模式應該說是——動態(tài)地給一個對象添加一些額外的職責酷含。這句話是什么意思鄙早，怎么個動態(tài)法呢？
通過繼承的方式可以使子類具有父類的屬性和方法椅亚。子類繼承父類后限番，因為一些業(yè)務需求可以通過重寫的方式來加強父類的方法的一些功能，也可以重新定義某些屬性呀舔，即覆蓋父類的原有屬性和方法弥虐，使其獲得與父類不同的功能。而裝飾者模式媚赖，最基本的功能就是對傳入的一個對象進行功能的加強與優(yōu)化霜瘪。
大學課本里面關于裝飾者模式，舉過類似買咖啡加奶加蜂蜜等不同調料算最終總價的例子惧磺。我在網(wǎng)上找到另一個類似的例子颖对，買豆?jié){。
通過上面兩點疑惑的思考，及對裝飾者模式代碼的熟悉后考润，希望大家對什么情景下能使用裝飾者模式能有一定的認識狭园。
