定义
饰模式指的是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。
UML结构图
- Component：组件对象接口
- ConcreteComponent：具体的组件对象，实现组件对象接口，通常就是被装饰的原始对象。就对这个对象添加功能。
- Decorator：所有装饰器的抽象父类，需要定义一个与组件接口一致的接口，内部持有一个Component对象，就是持有一个被装饰的对象。
- ConreteDecoratorA/ConreteDecoratorB：实际的装饰器对象，实现具体添加功能
抽象组件接口
/**
- 统一的组价对象接口
*/
public abstract class Component {
//抽象方法 没有具体操作
public abstract void operate();
}
具体实现类，被装饰者
/**
* 具体实现组件对象接口的对象 被装饰的原始对象
*/
public class ConcreteComponent extends Component {
@Override
public void operate() {
//重写方法 做基本的操作
System.out.print("去约妹子！");
}
}
抽象的装饰者，持有一个被装饰者的引用
/**
* 所有装饰器的抽象父类 持有接口 转发请求
*/
public abstract class Decorator extends Component {
/**
* 内部持有的组件接口对象
*/
protected Component component;
public Decorator(Component component) {
this.component = component;
}
/**
* 转发请求给组件对象 这里可以做一些附加操作
*/
@Override
public void operate() {
component.operate();
}
}
两个装饰者
/**
* 某个具体装饰器实现对象，调用接口方法和具有自己的方法 并能够附加上去
*/
public class ConcreteDecoratorA extends Decorator{
public ConcreteDecoratorA(Component component) {
super(component);
}
public int operateA(){
System.out.print("A约妹子之前要弄个帅气的发型");
return 0;
}
@Override
public void operate() {
operateA();
super.operate();
}
}
public class ConcreteDecoratorB extends Decorator{
public ConcreteDecoratorB(Component component) {
super(component);
}
public int operateB(){
System.out.print("B约妹子之前要弄身漂亮衣服");
return 0;
}
@Override
public void operate() {
operateB();
super.operate();
}
}
客户端调用
public class Client {
public static void main(String[] args){
Component component = new ConcreteComponent();
ConcreteDecoratorA concreteDecoratorA = new ConcreteDecoratorA(component);
ConcreteDecoratorB concreteDecoratorB = new ConcreteDecoratorB(component);
concreteDecoratorA.operate();
concreteDecoratorB.operate();
}
}
输出内容
A约妹子之前要弄个帅气的发型
去约妹子！
B约妹子之前要弄身漂亮衣服
去约妹子！
- 装饰者模式实现的是从一个对象外部给对象添加功能，相当于改变了对象的外观，装饰过的对象，从外部系统来看已经不再是原来的对象，而是经过一系列装饰器装饰过的对象。
- 装饰者模式最大的好处就是灵活，它能够灵活的改变一个的对象的功能，并且是动态组合形式。另外好处就是代码复用，因为每个装饰器是独立的，可以给一个对象多次增加同一个装饰器，也可以同一个装饰器装饰不同对象。
Android中的装饰者模式
经常使用的Context其实用的就是包装模式
我们知道Activity、Services、Application他们都继承了ContextWrapper类。根据这个名字就觉得这是一个装饰类。装饰类里面会持有一个被装饰者的引用
package android.content;
public class ContextWrapper extends Context {
Context mBase;
public ContextWrapper(Context base) {
mBase = base;
}
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
@Override
public AssetManager getAssets() {
return mBase.getAssets();
}
}
是不是似曾相识的感觉,这就是Context的装饰类,有兴趣的童鞋可以继续在源码中看下去,下面看下他们几个的关系
优点
是继承的一种替代方案，但是比继承要灵活的多，可以在运行时通过传入不同的被装饰器或不同的装饰器来达成不同的行为。
增加新的被装饰类和装饰类很方便，而且不用修改原有代码。便于拓展。符合开闭原则。
缺点
设计模式基本都有这个缺点，就是会生成额外的类，增加系统复杂度。
由于装饰可以层层包装，交叉包装，如果包装的很深的话，调试排错会比较麻烦，也不容易理解。
总结
- 设计模式在写代码中经常使用到，并且非常重要。有时只是我们使用了而没有注意到它的存在。
我认为理解了设计模式再来看Android源码才能透过现象看本质，没有理解设计模式，看源码时候会纠结在源码的汪洋大海。理解了23种设计模式并能够区分理解运用，看源码就能从更高的层次理解。 - 装饰模式和前面的代理模式有点类似，容易把装饰模式看成代理模式。装饰模式是继承的一种替代方案，主要为所装饰的对象增强功能，动态的增加方法。而代理模式主要是为了控制对原有对象的访问权限，不对原有对象进行功能增强。
