android设计模式-装饰模式(Decorator Pattern)

版权声明:本文为博主原创文章,未经博主允许不得转载。技术交流可邮:[email protected] https://blog.csdn.net/cjh94520/article/details/71036298

什么是装饰模式

装饰模式:动态地给一个对象添加一些额外的职责,本质就是拓展,不改变原有的代码结构。

类图

这里写图片描述

装饰模式的解析

如上图,首先Component提供一个接口让别人去实现,在装饰模式下,一定有实现类ConcreteComponent,该类implements Component,提供具体实现的方法。同时,提供Decorator类,该类是一个装饰类,并不提供实际功能,但类内有成员变量Component,通过set方法去获取具体的实现类,也就是ConcreteComponent。所以其实Decorator相当于一个代理类。一般情况下,我们继承Decorator,然后在子类添加一些额外的职责。

装饰模式的好处

  1. 首先,装饰模式符合开闭原则,对扩展开放,对修改关闭,当我们需要额外添加不同的职责的时候,可以选择继承Decorator类,从而不影响原来的结构
  2. 装饰模式本身职责分明。在设计装饰模式时,一般将统一的部分(或者说不易改变的部分)放在实现类,而类的具体额外职责由代理类的子类去实现,这样整体看结构清晰。其实本来使用设计模式,目的就是要设置各种规范,去限制程序员按既有的规则写代码,当程序员知道这是一个装饰模式时候,默认情况下会选择继承Decorator类,不去轻易改动这个ConcreteComponent实现类。这个好处最好跟不用设计模式相对比一下,当你不用设计模式,去实现额外的职责时候,必须在子类去实现,但这种情况下有可能出现类爆炸的情况,若果将这种额外的职责放在父类,这样一定程度会影响后面开发的结构,很难去干扰别的程序员去判断这种额外职责的归属。

装饰模式在Android的应用

最常见的就是Context类了。
这里写图片描述

ContextWrapper是对ContextImpl类的包装,Service类和Activity类都是ContextWrapper的派生类,Service类直接派生自ContextWrapper,Activity间接派生自ContextWrapper的子类ContextThemeWrapper,Service类和Activity类分别在ContextWrapper和ContextThemeWrapper类的接口基础上添加和实现了各自的生命周期回调接口,Activity类还提供了与其相关的窗口和视图显示相关的功能。ContextThemeWrappe的功能是在ContextWrapper基础上添加了对主题(Theme)的支持。

深入ContextImpl源码,里面存在最重要的东西就是LoadedApk类(mPackageInfo实例),里面存在当前类的相关信息,包名,权限,资源。这种东西对一个应用来说是应该共用且不变的,所以放在ContextImpl里面,代理类Context需要使用的时候就取,当我们需要实现额外的职责,比如Service类,需要执行初始化onStartCommand(),结束stopSelf(),就可以在继承装饰类进行实现,整个结构非常清晰。

总结

上面就是我对装饰模式的理解,我的关注点其实相对别人来说,更关注的是结构方面,我觉得能够符合开闭原则添加职责是一个加分点,但能够清晰将需要改动和不改动的地方分开存放,需要的时候再并合使用,我觉得用起来更有意义。

猜你喜欢

转载自blog.csdn.net/cjh94520/article/details/71036298