设计模式-装饰者模式
简述
装饰者模式(Decorator Pattern)也称为包装模式(Wrapper Pattern),以透明动态的方式来动态扩展对象的功能,也是继承关系的一种代替方案。
- Component:抽象组件(可以是抽象类或者接口),被装饰的原始对象
- ConcreteComponent:具体实现类,被装饰的具体对象
- Decorator:抽象装饰者,职责就是为了装饰我们的组件对象,内部一定要有一个指向组件对象的引用
- ConcreteDecoratorA:装饰者具体实现类,只对抽象装饰者做出具体实现
- ConcreteDecoratorB:同上
举个栗子
人定义为抽象类,有一个抽象方法eat()
1 | public abstract class Person { |
接着创建一个NormalPerson类继承Person,对eat()方法有了具体实现;NormalPerson类就是我们需要装饰的对象。
1 | public class NormalPerson extends Person { |
这里定义一个PersonFood类来表示装饰者的抽象类,保持了一个对Person的引用,可以方便调用具体被装饰的对象方法,这样就可以方便的对其进行扩展功能,并且不改变原类的层次结构。
1 | public class PersonFood extends Person { |
接着就是具体的装饰类了,这两个类没有本质上的区别,都是为了扩展NormalPerson类,不修改原有类的方法和结构
1 | public class ExpensiveFood extends PersonFood { |
使用装饰者代码:
1 | public class Client { |
android中的装饰者模式
在android中,Context就是典型的装饰者模式,Context是抽象类,真实的功能实现实在ComtextImpl中完成,ComtextImpl就是Context的实现类;然后看源码会发现Activity是继承于ContextThemeWrapper而不是直接继承于Context。其中ContextThemeWrapper继承于ContextWrapper,而ContextWrapper继承于Context。这里就可以看出来一点装饰者模式了,其中装饰者所调用的方法就是startActivity方法,在ContextWrapper中会发现startActivity方法调用了ComtextImpl中对应的方法,实质上ContextWrapper中所有方法都仅仅是调用了ComtextImpl中的方法,这就和装饰者模式基本就对应上了。
想具体了解Context机制可以看我另一篇文章:Android源码小记-Context解析
小结
优点
- 装饰者模式与继承关系的目的都是要扩展对象的功能,但是装饰者模式可以提供比继承更多的灵活性。
- 通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
缺点
- 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
- 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
- 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时,就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口,增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
装饰者模式与代理模式对比
其实装饰者模式和代理模式很像,但是两者的目的不尽相同。装饰者模式是以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案;而代理模式则是一个给对象提供一个代理对象,并由代理对象来控制对原有对象的引用。
装饰者模式为本装饰的对象进行功能扩展;代理模式对代理对象进行控制,但不做功能扩展