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

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

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

我们可以看下示意图
认真学习设计模式之委派模式(Delegate Pattern)_任务分配
也就是说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并没有限制死而是根据具体业务场景动态变化,是不是又有策略模式的影子了?