装饰者模式之Context应用（二）

上篇文章提到了Context及其子类源码分析（一），这篇文章我们来讲讲Context及其子类用到的设计思想——装饰者模式。

（一）装饰者模式UML

装饰者模式UML

Component抽象构件角色：真实对象和装饰对象有相同的接口。这样，客户端对象就能够以与真实对象相同的方式同装饰对象交互。相当于Context。
ConcreteCompoent具体构建角色(真实对象)：定义一个将要接收附加责任的类。相当于ContextImpl。
Decorator装饰角色：持有一个抽象构件的引用，用set方法将真实对象塞入Decorator装饰角色中。装饰对象接受所有客户端的请求，并把这些请求转发给真实的对象。这样，就能在真实对象调用前后增加新的功能。相当于ContextWrapper。
ConcreteDecorate具体装饰角色：负责给构件对象增加新的功能。相当于ContextThemeWrapper、Activity、Service和Application。
大家可以去看上一篇文章：Context及其子类源码分析或者自己打开源码查看，Context及其子类就是活脱脱的装饰者模式。

（二）为什么用装饰者模式

看了很多关于为什么要用装饰者模式的博客，但是都没真正明白为装饰者模式的应用场景，只记得别人一直强调装饰者模式可以在不修改原类的代码的情况下，进行功能扩展。

（1）直到我想到代理模式好似也有扩展功能的作用，那么，二者有什么区别呢？

我找到了这篇文章——设计模式：代理模式与装饰模式。里面有代码例子，写的特别详细。大家一定要看看，如果你觉得看的乱的话，那一定是因为你对两种模式的代码不熟悉，怎么办？把代码背下来啊！静下心不要浮躁，反正我是看了很多遍很多遍两种模式的代码。然后对比类中有什么变量、实现了什么接口、到底继承自哪个类、客户端怎么调用调用。

简而言之，装饰者模式的ConcreteCompoent具体构建角色和Decorator装饰角色都继承自抽象类Component抽象构件角色，Decorator装饰角色中有ConcreteCompoent具体构建角色的引用，客户端调用时候，会出现ConcreteCompoent具体构建角色的类。

而静态代理模式的代理类和被代理类同样是实现了同一个接口或继承自同一个类。区别是，代理类中实例了被代理对象，即代理类和被代理类是组合关系。而客户端调用的时候，并不需要实例被代理类。

当然了，代理类在调用被代理的方法时候可以适当的增加一些功能，作为功能扩展。但是相对的，装饰模式主要是强调对类中代码的拓展，而代理模式则偏向于委托类的访问限制。两者的出发点是不一样的。因为客户端并不需要知道你到底代理了哪个类，我直接调用代理类的方法，而代理类内部怎么调用被代理类，我客户端不关心。这就是所谓的偏向于为委托类的访问限制。

（2）继承也可以扩展父类功能，那为什么还要用装饰者模式呢？
其实装饰者模式应该说是——动态地给一个对象添加一些额外的职责。这句话是什么意思，怎么个动态法呢？

通过继承的方式可以使子类具有父类的属性和方法。子类继承父类后，因为一些业务需求可以通过重写的方式来加强父类的方法的一些功能，也可以重新定义某些属性，即覆盖父类的原有属性和方法，使其获得与父类不同的功能。而装饰者模式，最基本的功能就是对传入的一个对象进行功能的加强与优化。

大学课本里面关于装饰者模式，举过类似买咖啡加奶加蜂蜜等不同调料算最终总价的例子。我在网上找到另一个类似的例子，买豆浆。

类爆炸

这图想表达什么意思呢？假设最开始你有个豆浆类，要实现图里的功能，用继承的方式，你要写14个继承自豆浆类的新类。整个系统就很臃肿。但如果你采用装饰者模式，那么只要多写糖、蜂蜜、黑豆、牛奶4个类而已。然后根据需求自己客户端调用的时候，随意动态组合。另外说明： 各个装饰器之间最好是完全独立的功能，不要依赖，这样在进行装饰组合的时候，才没有先后调用限制。否则会降低装饰器组合的灵活性。

通过上面两点疑惑的思考，及对装饰者模式代码的熟悉后，希望大家对什么情景下能使用装饰者模式能有一定的认识。