认真学习设计模式之委派模式(Delegate Pattern)

委派模式不属于GOF23种设计模式, 主要角色有三种: 抽象任务角色, 委派者角色, 具体任务角色。

委派模式具体是指定义一个抽象接口, 它有若干实现类, 他们真正执行业务方法, 这些子类是具体任务角色。定义委派者角色也实现该接口, 但它负责在各个具体角色实例之间做出决策, 由它判断并调用具体实现的方法。联想到工作中就是leader将任务分派给小组长，小组长进行任务具体拆分到个人。

通常委派模式对外隐藏了具体实现, 仅将委派者角色暴露给外部。是不是立马想到了外观？如果委派者和具体的ConcreteTask也暴露出去可以吗？

我们可以看下示意图

也就是说Delegate与ConcreteTask是同一种类型，实现了同样的方法。在委派者处理任务时，会将具体任务动作分派给ConcreteTask。

我们来看下一种变异的委派模式-mybatis中的CachingExecutor

如下所示，CachingExecutor 的构造方法中拥有delegate对象(这里可以理解为执行工作任务的对象)。

public class CachingExecutor implements Executor {

 private final Executor delegate;
 private final TransactionalCacheManager tcm = new TransactionalCacheManager();

 public CachingExecutor(Executor delegate) {
   this.delegate = delegate;
   delegate.setExecutorWrapper(this);
 }
}

以update方法为例，如下所示，在进行必要的增强方法flushCacheIfRequired(ms);后，将任务分配给了delegate调用其update方法。这里是不是又有装饰器的影子？

@Override
public int update(MappedStatement ms, Object parameterObject) throws SQLException {
  flushCacheIfRequired(ms);
  return delegate.update(ms, parameterObject);
}

那么delegate是什么呢？由构造函数传入。比如可以是SimpleExecutor也可以是BatchExecutor。所以这里delegate并没有限制死而是根据具体业务场景动态变化，是不是又有策略模式的影子了？