会写代码是门槛，写好代码是本事
前言
平时写代码的时候可能为了完成某一个任务而只是应付性地编码，然后写完理直气壮地来一句"又不是不能用！"，但如果要把编码当作一项艺术来打造，那就需要结合我们的设计模式了。设计模式可以运用在诸多方面，让我们的代码更加优雅。设计模式在Android中也是无处不在，动态代理、建造者、工厂、适配器....等等等等，可见它对我们的重要性。最近在看Retrofit的源码，刚好看到了动态代理，想着总结下这个模式。
什么是装饰器模式？
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，相当于对现有的类的一个包装。
你可能会反驳，继承不就可以对现有对象进行拓展了吗？继承是可以实现同样效果，但是由于Java是单继承，如果你多级包装，子类会越来越多，层级越来越深，而利用装饰器模式则可以优雅解决这个问题。它动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比继承更为灵活。
如何实现装饰器模式？
以绘制形状为例，我们平时绘制的形状五花八门，可能有圆形、矩形、三角形...等等，我们抽取出一个抽象的形状接口：
/**
* 形状接口
*/
public interface Shape {
//定义公用的形状绘制方法
void onDraw();
}
接下来，假如我们要绘制一个圆形，会实现Shape接口，定义具体绘制圆形的方法：
/**
* 圆形类
*/
public class Circle implements Shape{
@Override
public void onDraw() {
Log.d("Decorator", "绘制一个圆形");
}
}
假如某一天，有一个特殊的需求，需要绘制一个带边框的圆形，但又不允许更改Circle类，如果是按继承写法会是如下：
/**
* 带边界的圆形
*/
public class BorderCircle extends Circle{
@Override
public void onDraw() {
super.onDraw();
Log.d("Decorator","绘制一条边界");
}
}
效果是实现了，也没出现啥问题，等到某一天，又来了个需求，要绘制一个带边界的渐变圆，且依然不能修改原来的类，你也许会想，那就继续继承BorderCircle就好了......如此反复循环，继承的具体形状类会越来越多，且可能会嵌套了很多层，不利于代码的维护。
我们将以上改为装饰器模式来实现的话，可以先定义一个抽象装饰者来装饰Shape：
/**
* 抽象装饰者类，对Shape接口进行包装
*/
public class ShapeDecorator implements Shape{
private Shape shape;
public ShapeDecorator(Shape shape) {
this.shape = shape;
}
@Override
public void onDraw() {
shape.onDraw();
}
}
然后假如是实现一个带边界的圆形，就是如下写法：
/**
* 带边界的圆形
*/
public class BorderCircle extends ShapeDecorator{
public BorderCircle(Shape shape) {
//调用父类的构造方法，将参数传给父类
super(shape);
}
@Override
public void onDraw() {
//调用父类的onDraw
super.onDraw();
Log.d("Decorator","绘制一条边界");
}
}
假如想要加个渐变，就不需要再进一步继承于BorderCircle了，而是依旧继承于ShapeDecorator：
/**
* 带边界的渐变圆形
*/
public class GradientBorderCircle extends ShapeDecorator{
public GradientBorderCircle(Shape shape) {
super(shape);
}
@Override
public void onDraw() {
super.onDraw();
Log.d("Decorator", "绘制渐变");
}
}
最终客户端调用姿势如下：
Shape circle = new Circle();
//绘制一个带边界的圆形
ShapeDecorator borderCircle = new BorderCircle(circle);
borderCircle.onDraw();
//绘制一个带边界且渐变的圆形
ShapeDecorator gradientBorder = new GradientBorderCircle(borderCircle);
gradientBorder.onDraw();
Context中的装饰器模式
Android源码中也有很多地方用到了这种设计思想，最经典的Context就使用了这种模式，Context对于我们来说都不陌生，它代表了当前的上下文对象，它本身是一个抽象类：
Context相当于一个【被装饰者抽象类】
它有一个子类
ContextWrapper，可以看到它持有Context对象，并且在构造方法中赋值，是不是类似于上面例子中的抽象装饰者类：
ContextWrapper持有Context的引用，它是一个【抽象装饰者】的角色
而ContextWrapper的子类就有我们最熟悉的Activity、Service、Application等，它们都相当于Context的具体装饰者，各自有各自的特点。
那么问题来了，相比刚才的例子好像还缺一个角色没有提到——具体被装饰者类，刚才说了，ContextWrapper是具体装饰者，那么它持有的这个Context对象是哪里传进来的呢？我们以Application为例，探究下Application中调用attachBaseConetxt的地方：
/* package */
final void attach(Context context) {
attachBaseContext(context);
mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
}
在Application的attach方法中调用了attachBaseContext，我们继续往上跟踪，看下哪里调用了attach：
static public Application newApplication(Class<?> clazz, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = (Application)clazz.newInstance();
app.attach(context);
return app;
}
Instrumentation类创建了Application，并且将context绑定给它，那么这个newApplication又是哪里调用的呢？
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
Application app = null;
try {
//....忽略部分代码
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
//....忽略部分代码
}
mActivityThread.mAllApplications.add(app);
mApplication = app;
//....忽略部分代码
return app;
}
到这一步，可以看到原来传递进去的Context对象是一个ContextImpl类型，那么ContextImpl极有可能就是我们的具体被装饰者，我们验证一下，点击去可以看到ContextImpl确实是继承于Context的：
public final class ContextImpl extends Context {
它们的关系图如下：
Context Uml
ContextWrapper中实现Context的方法全是通过它持有的mBase对象来实现的。这样它（ContextWrapper）派生出的子类就可以在不改变原始context（mBase）的情况下扩展Context的行为。无论是Activity、Service还是Application，它们本质都是
ContextWrapper，都是Context的一个具体装饰者的角色，都是在ContextImpl的基础上进一步拓展各自的特色功能和逻辑。总结
装饰模式降低了系统的耦合度，可以动态增加或删除对象的职责，并使得需要装饰的具体构件类和具体装饰类可以独立变化，以便增加新的具体构件类和具体装饰类。装饰模式应用较为广泛，不止Android，例如在 JavaIO 中的输入流和输出流的设计也同样运用了该模式。当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰器模式。
关注Android 技术小栈，一起交流Android开发的那些事
网友评论