0. 序言
为了更好的梳理Context、ContextWrapper、ContextImpl、ContextThemeWrapper、Service、Application、Activity之间的关系，我们先来看下设计模式之装饰模式。
1. 定义
装饰模式是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，通过装饰来包裹真实的对象。
2. UML类图
装饰模式.png
3. 示例
- Component
public abstract class Component {
public abstract void operate();
}
- ConcreteComponent
public class ConcreteComponent extends Component{
@Override
public void operate() {
}
}
- Decorator
public class Decorator extends Component {
private Component mComponent;
public Decorator(Component component) {
mComponent = component;
}
@Override
public void operate() {
mComponent.operate();
}
}
- ConcreteDecoratorA
public class ConcreteDecoratorA extends Decorator{
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void operate() {
operateA();
super.operate();
operateB();
}
private void operateA() {
}
private void operateB() {
}
}
- ConcreteDecoratorB
public class ConcreteDecoratorB extends Decorator{
public ConcreteDecoratorB(Component component) {
super(component);
}
@Override
public void operate() {
operateA();
super.operate();
operateB();
}
private void operateA() {
}
private void operateB() {
}
}
- Main
public class Main {
public static void main(String[] args) {
Component component = new ConcreteComponent();
Decorator decoratorA = new ConcreteDecoratorA(component);
decoratorA.operate();
Decorator decoratorB = new ConcreteDecoratorB(component);
decoratorB.operate();
}
}
以上角色介绍：
- Component: 抽象组件
可以是接口或抽象类，其充当的就是被装饰的原始对象。 - ConcreteComponent: 组件具体实现类
该类是Component类的基本实现，其充当的是装饰的具体对象 - Decorator: 抽象装饰者
该类承担的职责就是为了装饰我们的组件对象，所以其内部一定要有一个指向组件对象的引用。在大多数情况下，该类是抽象类，子类需要根据不同的装饰逻辑实现不同的具体子类。当然，如果装饰逻辑单一，只有一个子类的情况下，可以省略该类直接作为具体的装饰者。 - ConcreteDecoratorA和ConcreteDecoratorB: 装饰者具体实现类
只是对抽象装饰者作出具体的实现。 - Main: 客户端类
4. 特点
- 装饰对象和真实对象有相同的接口。这样客户端就能以和真实对象相同的方式和装饰对象交互。
- 装饰对象包含真是对象的一个引用。
- 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。
- 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就能确保在运行时，不用修改给定对象的内部结构，就能在外部增加附加的功能。在面向对象的设计中，通常通过继承来实现对给定对象的扩展。
5. 优点
- 装饰模式和继承都是为了对给定对象进行扩展，只是装饰模式更加灵活。
- 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
6. 缺点
- 增加灵活性的同时，增加了复杂性。
- 装饰者的设计会增加很多小类，过度使用会使得程序变得异常复杂。
7. 设计原则
- 多组合，少继承。
利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。 - 类应该设计得对修改关闭，对扩展开放。
8. 后续
如果大家喜欢这篇文章，欢迎点赞！
如果想看更多 设计模式 方面的文章，欢迎关注!
你的点赞和关注，是对我莫大的支持和鼓励，我将会花更多的时间和精力在分享技术上！
