对于任何一个软件系统而言，往现有对象中添加新功能是一种不可避免的实现场景，但这一实现过程对现有系统的影响可大可小。从架构设计上讲，我们也知道存在一个开闭原则（Open-Closed Principle，OCP），也就是说设计需要确保对扩展开放、对修改关闭。
通过开闭原则就能确保新的功能对现有系统的影响最小。那么，问题就来了，开闭原则只是提供了一种方法论支持，我们应该如何来具体实现这一原则呢？方法有很多，而今天我们要介绍的装饰器设计模式就是其中一种具有代表性的实现方式，在Mybatis、Apache ShardingSphere等主流开源框架中应用广泛。
装饰器模式的基本概念和简单示例
在面向对象的世界中，我们通常使用接口来定义业务操作。例如，在如下所示的Shape接口中，我们定义了一个用来绘制形状的操作方法draw。
public interface Shape {
//绘制形状
void draw();
}
有了Shape接口之后，我们来设计两个实现类，分别是Circle和Rectangle。代码X。
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Shape: Circle");
}
}
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Shape: Rectangle");
}
}
这几个接口和类之间的关系比较简单，如下图所示。
现在，新需求来了，我们需要在绘制形状的基础上对该形状添加边框。显然，这时候就需要对现有的Circle和Rectangle类添加新的功能。基于装饰器模式，我们不是直接对这两个类做出代码上的调整，而是引入一个抽象类ShapeDecorator。
public abstract class ShapeDecorator implements Shape {
protected Shape decoratedShape;
public ShapeDecorator(Shape decoratedShape) {
this.decoratedShape = decoratedShape;
}
public void draw() {
decoratedShape.draw();
}
}
这个ShapeDecorator就是装饰器类，在实现了Shape接口的同时又在内部包含了对Shape的引用，通过这个引用完成对接口方法的实现。这种设计就是装饰器模式的基本实现策略。
然后我们来看ShapeDecorator的一个实现类RedShapeDecorator，该类添加了绘制边框的额外功能，即提供了装饰实现。
public class RedShapeDecorator extends ShapeDecorator {
public RedShapeDecorator(Shape decoratedShape) {
super(decoratedShape);
}
@Override
public void draw() {
decoratedShape.draw();
//添加绘制边框的额外功能
setRedBorder(decoratedShape);
}
private void setRedBorder(Shape decoratedShape) {
System.out.println("Border Color: Red");
}
}
而在具体使用上，我们发现这个装饰类和其他类实际上没有什么区别，即只要是使用Shape接口的地方都可以使用这个包装类。
Shape circle = new Circle();
Shape redCircle = new RedShapeDecorator(new Circle());
Shape redRectangle = new RedShapeDecorator(new Rectangle());
circle.draw();
redCircle.draw();
redRectangle.draw();
运行上述代码，我们可以得到如下所示的结果。
Shape: Circle
Shape: Circle
Border Color: Red
Shape: Rectangle
Border Color: Red
上述实现过程虽然比较简单，但已经把一个装饰器模式的完整结构都介绍清楚了。作为总结，我们可以梳理如下所示的类层结构图。
接下来，我们来对装饰器模式的特性做一个总结。从分类上讲，装饰器模式是一种典型的结构型设计模式，允许向一个现有的对象添加新的功能，但又能做到不改变其结构。这种模式创建了一个装饰类，用来对原有类进行包装，并在保持类方法签名完整性的前提下，提供了额外的功能。本质上，装饰器模式的目的是为了动态地给一个对象添加一些额外的职责，相比直接生成子类，这种方式实现起来可以更为灵活。
从使用时机上讲，装饰器模式可以在不想增加很多子类的情况下扩展类，所以通常被认为是继承机制的一个替代模式。正如前面所述的示例一样，具体做法就是将业务功能按职责进行划分并集成装饰者模式。这样装饰类和被装饰类可以独立发展，不会相互耦合。
装饰者模式在Mybatis中的应用与实现
介绍完装饰器模式的基本概念和示例，接下来讨论它的具体应用方式，我们以主流的ORM框架Mybatis为例展开讨论。装饰器模式在Mybatis中的主要应用是在对缓存（Cache）的处理上。在Mybatis中，缓存的功能由根接口Cache定义。
public interface Cache {
String getId();
void putObject(Object key, Object value);
Object getObject(Object key);
Object removeObject(Object key);
void clear();
int getSize();
default ReadWriteLock getReadWriteLock() {
return null;
}
}
围绕Cache接口的类层结构如下图所示。在该图中，Cache接口代表一种抽象，而处于图中央的PerpetualCache代表该接口的具体实现类，位于org.apache.ibatis.cache.impl包中。而其他所有以Cache结尾的类都是装饰器类，位于org.apache.ibatis.cache.decorators包中。
在上图中，整个缓存体系采用装饰器设计模式，数据存储和缓存的基本功能由PerpetualCache类实现，该类实际上采用的就是一种基于HashMap的简单实现策略。
public class PerpetualCache implements Cache {
private final String id;
private Map<Object, Object> cache = new HashMap<>();
public String getId() {...}
public int getSize() {...}
public void putObject(Object key, Object value) {...}
public Object getObject(Object key) {...}
public Object removeObject(Object key) {...}
public void clear() {...}
}
可以看到，整个PerpetualCache类的代码结构非常明确，除了一个id属性之外，代表缓存的cache属性只是一个HashMap，是一种典型的基于内存的缓存实现方案。这里的几个方法也比较简单，所有对缓存的操作实际上就是对HashMap的操作。
Mybatis通过一系列的装饰器来对PerpetualCache永久缓存进行缓存策略等方面的控制。用于装饰PerpetualCache的标准装饰器包括BlockingCache、FifoCache、LoggingCache、LruCache等，我们通过名称就可以判断出这些装饰类所要装饰的功能。下图展示了这些缓存类之间的类层关系。
我们无意对所有这些装饰类做全面展开，而是只挑选其中一个来说明装饰器模式的应用方式，这里我们就选择FifoCache，该缓存类提供了FIFO（First Input First Output，先进先出）的缓存数据管理策略。
public class FifoCache implements Cache {
private final Cache delegate;
private final Deque<Object> keyList;
private int size;
public FifoCache(Cache delegate) {
this.delegate = delegate;
this.keyList = new LinkedList<>();
this.size = 1024;
}
@Override
public String getId() {
return delegate.getId();
}
@Override
public int getSize() {
return delegate.getSize();
}
public void setSize(int size) {
this.size = size;
}
@Override
public void putObject(Object key, Object value) {
cycleKeyList(key);
delegate.putObject(key, value);
}
@Override
public Object getObject(Object key) {
return delegate.getObject(key);
}
@Override
public Object removeObject(Object key) {
return delegate.removeObject(key);
}
@Override
public void clear() {
delegate.clear();
keyList.clear();
}
private void cycleKeyList(Object key) {
keyList.addLast(key);
if (keyList.size() > size) {
Object oldestKey = keyList.removeFirst();
delegate.removeObject(oldestKey);
}
}
}
以上代码虽然比较冗长，但却简单明了。关键点在于我们引用了Cache接口，并在具体对缓存的各个操作中调用了该接口中的缓存管理方法。因为这里实现的是一个先进先出的策略，所有，我们通过使用一个Deque对象来达到这种效果，这也让我们间接掌握了实现FIFO机制的一种实现方案。
当我们想使用各种缓存类时，可以通过如下所示的方式实现装饰。
Cache cache = new XXXCache(new PerpetualCache("cacheid"))
如果把这里的XXXCache替换成FifoCache就代表着这个新创建的Cache对象具备了FIFO功能。其他缓存装饰器类的使用方法也是一样。
如果你正在考虑往系统对象中添加新功能，不妨先停下来分析所需新功能对现有对象的影响。如果我们需要对现有对象的结构进行比较大的调整，那么说明在类的设计上可能存在不符合开闭原则的坏味道。这时候，我们可以引入今天内容所介绍的装饰器模式对其进行重构。装饰器模式是一种非常有用的设计模式，我们通过基本的实现代码示例给出了它的实现方法。
实现装饰器模式的前提是我们需要采用面向接口的编程模式，然后对功能的类型和职责进行合理的划分，确保不同的装饰器类能够独立承接不同的业务功能。一旦构建了符合装饰器模式的代码框架结构，那么通过构建各种装饰器类，我们就可以为系统添加丰富的新功能。正如Mybatis中Cache接口及其各种装饰器类所展示的那样。