设计模式之装饰者模式

装饰模式介绍和结构

装饰者模式：动态的给一个对象添加一些额外的职责。

装饰者模式的使用场景：

1. 在不影响其他对象的情况下，以动态、透明的方法给单个对象添加职责。
2. 处理那些可以撤销的职责。（所有的职责均不可撤销的话则使用继承可以更好的进行扩展）。
3. 当不能使用生成子类的方法进行扩充时。这一般包含两种情况。一种情况是可能有大量独立扩展、为支持每一种组合而需要产生大量子类，使得子类数目呈爆炸式增长。另一种情况就是，类定义被隐藏或者类被定义为不能生成子类。

装饰者模式的角色：

• Component：定义一个接口。可以给这些对象动态的添加职责。
• ConcreteComponent：定义一个对象，可以给这些对象动态的添加职责。
• Decorator：维持一个指向Component对象的指针，并定义一个与Component接口一致的接口。
• ConcreteDecorator：向组件添加职责。

装饰者模式的结构图如下：

装饰者模式示例代码

接下来来看一下装饰者的实例代码：
这里以相机拍照，然后可以加美颜，加滤镜等扩展功能，首先我们定义拍照功能集合接口：

**
 * 定义具有拍照功能工具，如手机、相机等，
 * 这里定义的为手机
 */
class PhonePhotograph implements Photograph {

    @Override
    public void takePicture() {
        System.out.println("拍摄原始照片");
    }
}

实现拍照功能的手机类：

/**
 * 定义具有拍照功能工具，如手机、相机等，
 * 这里定义的为手机
 */
class PhonePhotograph implements Photograph {

    @Override
    public void takePicture() {
        System.out.println("拍摄原始照片");
    }
}

装饰者抽象类及实现，分为添加滤镜和美颜：

/**
 * 定义抽象照片处理器，这里是对拍照的
 * 图片进行处理
 */
abstract class PhoneDealer implements Photograph {
    protected Photograph photograph;


    protected PhoneDealer(Photograph photograph) {
        this.photograph = photograph;
    }

    @Override
    public void takePicture() {
        photograph.takePicture();
    }
}

/**
 * 添加滤镜处理实现
 */
class FilterPhoneDealer extends PhoneDealer {

    protected FilterPhoneDealer(Photograph photograph) {
        super(photograph);
    }

    @Override
    public void takePicture() {
        System.out.println("添加滤镜");
        super.takePicture();
    }
}

/**
 * 添加美颜处理实现
 */

class PrettyPhoneDealer extends PhoneDealer {

    protected PrettyPhoneDealer(Photograph photograph) {
        super(photograph);
    }

    @Override
    public void takePicture() {
        System.out.println("添加美颜");
        super.takePicture();
    }
}

测试代码如下：

public class DecoratorTest {

    public static void main(String[] args) {
        Photograph photograph = new FilterPhoneDealer(new PrettyPhoneDealer(new PhonePhotograph()));
        photograph.takePicture();

    }
}

装饰者模式的优点和缺点

装饰者模式的优点：

1. 比静态继承更加的灵活。装饰者模式使用的是组合和委托的方式对原有功能对象增加扩展的功能，这些扩展功能并不是必须的，而是根据客户端的使用而动态变化的，所以使用起来更加的灵活，如果使用继承的话，为应对不必要的职责会增加子类的数量，导致系统复杂。
2. 避免在层次结构高层的类有太多特征。就像我们上面的实例一样，接口只是声明了拍照功能集合，而滤镜和美颜是在装饰者中添加的，高层的接口并不会声明动态扩展的功能。

装饰者模式的缺点：

1. Component与Decorator是不一样的。Component是真实的提供实际功能或者数据的。而Decorator是对已有的Component进行扩展的。所以说当装饰者设计复杂时，可能会不容易区分。就象IO中FileInputStream与BufferedInputStream一样，不看源码的或区分不了两者究竟谁是真正持有数据的。
2. 有许多小对象。当使用装饰者模式时，针对装饰者实现，会产生很多类似的对象，如果不仔细学习各个类的Api很容易进行混淆，就像JDK中IO中的FileInputStream、BufferedInputStream、DataInputStream、ObjectInputStream之间的相同点和区别一样。

装饰者模式在源码中的应用

JDK中IO使用装饰者模式

下图为JDK中输入流相关的接口和实现：

字节输入流中，ByteArrayInputStream和FileInputStream均为InputStream的具体实现，代表字节和文件数据,这两个为与装饰者模式中的ConcreteConponent相对应，而FilterInputStream为装饰者模式中的Decorator角色，其中BufferedInputSteam和DataInputStream为装饰者的具体实现，担任ConcreteDecorator角色。当然对于字符输入流的相关类，同样也是使用了装饰者模式，以及IO流中的输出流相关类。

Servlet中HttpServletRequest和HttpServletRequestWrapper

servlet中Servlet中HttpServletRequest和HttpServletRequestWrapper的结构如下：

这里的命名已经很清晰，就不再赘述。

Mybatis中缓存使用装饰者模式

在mybatis中缓存使用装饰者模式满足各种对缓存的功能需求，在Mybatis中缓存接口声明如下：

public interface Cache {

  String getId();


  void putObject(Object key, Object value);


  Object getObject(Object key);

  Object removeObject(Object key);

  void clear();


  int getSize();
  
  ReadWriteLock getReadWriteLock();

}

其中真正实现该接口并提供缓存的类为PerpetualCache：

public class PerpetualCache implements Cache {

  private final String id;

  private Map<Object, Object> cache = new HashMap<Object, Object>();

  public PerpetualCache(String id) {
    this.id = id;
  }

  @Override
  public String getId() {
    return id;
  }

  @Override
  public int getSize() {
    return cache.size();
  }

  @Override
  public void putObject(Object key, Object value) {
    cache.put(key, value);
  }

  @Override
  public Object getObject(Object key) {
    return cache.get(key);
  }

  @Override
  public Object removeObject(Object key) {
    return cache.remove(key);
  }

  @Override
  public void clear() {
    cache.clear();
  }

  @Override
  public ReadWriteLock getReadWriteLock() {
    return null;
  }

  @Override
  public boolean equals(Object o) {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    if (this == o) {
      return true;
    }
    if (!(o instanceof Cache)) {
      return false;
    }

    Cache otherCache = (Cache) o;
    return getId().equals(otherCache.getId());
  }

  @Override
  public int hashCode() {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    return getId().hashCode();
  }

}

而LruCache、ScheduleCache、SynchronizedCache等则是实现了功能的扩展，持有一个Cache对象，三个类的声明如下：

public class LruCache implements Cache {

  private final Cache delegate;
  private Map<Object, Object> keyMap;
  private Object eldestKey;

  public LruCache(Cache delegate) {
    this.delegate = delegate;
    setSize(1024);
  }
  // 省略代码。。。
}

public class ScheduledCache implements Cache {

  private final Cache delegate;
  protected long clearInterval;
  protected long lastClear;

  public ScheduledCache(Cache delegate) {
    this.delegate = delegate;
    this.clearInterval = 60 * 60 * 1000; // 1 hour
    this.lastClear = System.currentTimeMillis();
  }
  // 省略代码。。。


public class SynchronizedCache implements Cache {

  private final Cache delegate;
  
  public SynchronizedCache(Cache delegate) {
    this.delegate = delegate;
  }
  // 省略代码。。。
}