前言
本文将阐述设计模式中的责任链模式,包括责任链模式的应用场景、责任链模式与构造者模式的结合、框架源码分析等,最后综合阐述下责任链模式的优缺点。
希望可以帮忙大家更好的理解责任链模式。
责任链模式定义责任链模式(Chain of Responsibility Pattern)是将链中的每一个节点看做成一个对象,每个节点处理的请求均不同,且内部自动维护一个下一个节点对象,当一个请求从链式的首端发出时,会沿着链路的路径一次传递给每一个节点对象,直至有对象处理这个请求为止。
责任链模式是一种行为型设计模式。
应用场景总结下来责任链模式抽象的应用场景:
- 多个对象可以处理同一请求,但具体由哪个对象处理则在运行时动态决定。
- 在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
- 可动态指定一组对象处理请求。
在公司或公共机构办理事务时,通常会有很长很长的流程。一开始可能由保安或客服中心给你有流程的图纸,你按照图纸上的顺序,一个窗口一个窗口,或者一个部门一个部门去办理业务,每办理完成一个业务,对应的业务员就在图纸上盖一个章,代表已经处理完成。盖这个账很重要,表示了一种责任,如果出了问题是要负责的。但所有的流程都办理完成后,整个事项也就办理完成了。
过关打BOSS
相信很多朋友在平常闲暇时也会打打游戏放松放松,其中有一种游戏类型就是通关型游戏。每关的BOSS都会对这一关负责,只有打败了这一关的BOSS才能继续,每关的BOSS就负责这一关的任务,也可以简单看成一个责任链。
责任链模式实现
要实现责任链模式,首先需要定义具体的链路责任。看下继承关系图:
抽象处理者(Handler)角色:
定义出一个处理请求的接口。如果需要,接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者java接口实现。Handler类的聚合关系给出了具体子类对下家的引用,抽象方法handlerequest()规范了子类处理请求的操作。
具体实现类RequestHandler如下,核心是next属性。
public abstract class RequestHandler {
private final RequestHandler next;
/**
* Request handler.
*/
public void handleRequest(Request req) {
if (next != null) {
next.handleRequest(req);
}
}
protected void printHandling(Request req) {
LOGGER.info("{} handling request "{}"", this, req);
}
@Override
public abstract String toString();
}
具体处理者(ConcreteHandler)角色:
具体处理者接到请求后,可以选择将请求处理掉,或者将请求传给下一个节点。由于具体处理者持有对下一节点的引用,因此,如果需要,具体处理者可以访问下一节点。
本文定义了Soldier,Officer,Commander三种处理者。
public class Soldier extends RequestHandler {
public Soldier(RequestHandler handler) {
super(handler);
}
@Override
public void handleRequest(Request req) {
if (RequestType.COLLECT_TAX == req.getRequestType()) {
printHandling(req);
req.markHandled();
} else {
super.handleRequest(req);
}
}
@Override
public String toString() {
return "soldier";
}
}
public class Officer extends RequestHandler {
public Officer(RequestHandler handler) {
super(handler);
}
@Override
public void handleRequest(Request req) {
if (RequestType.TORTURE_PRISONER == req.getRequestType()) {
printHandling(req);
req.markHandled();
} else {
super.handleRequest(req);
}
}
@Override
public String toString() {
return "officer";
}
}
public class Commander extends RequestHandler {
public Commander(RequestHandler handler) {
super(handler);
}
@Override
public void handleRequest(Request req) {
if (RequestType.DEFEND_CASTLE == req.getRequestType()) {
printHandling(req);
req.markHandled();
} else {
super.handleRequest(req);
}
}
@Override
public String toString() {
return "commander";
}
}
上文中定义了具体的处理者。如何将处理者串联起来呢?我们定义了如下的King类,通过buildChain方法实现链路的串联。
public class King {
private RequestHandler chain;
public King() {
buildChain();
}
private void buildChain() {
chain = new Commander(new Officer(new Soldier(null)));
}
public void makeRequest(Request req) {
chain.handleRequest(req);
}
}
上文中我们简单实现了责任链模式。但是上述的实现真的优雅吗?
有些同学可能已经发现。在最终构建chain时,使用new Commander(new Officer(new Soldier(null)))方式实现的看着很不爽,特别是,这里有三种处理者还比较容易编写,但是当有更多的处理者时,这个构建就会相当的复杂。
因此,我们可以将责任链模式和构造者模式相结合。这样可以使得代码变得更加优雅,扩展性更好,仅需要addHandler即可。
第一步:调整RequestHandler,增加一个内部类Builder。
public abstract class RequestHandler<T> {
protected RequestHandler next;
/**
* Request handler.
*/
public void handleRequest(Request req) {
if (next != null) {
next.handleRequest(req);
}
}
protected void printHandling(Request req) {
LOGGER.info("{} handling request "{}"", this, req);
}
@Override
public abstract String toString();
public static class Builder<T> {
private RequestHandler<T> head;
private RequestHandler<T> tail;
public RequestHandler<T> build() {
return this.head;
}
public Builder<T> addHandler(RequestHandler<T> handler) {
if (this.head == null) {
this.head = this.tail = handler;
}
this.tail.next = handler;
this.tail = handler;
return this;
}
}
}
第二步:修改build方法,与上文的不断new的方法相比更加优雅。
private void buildChain() {
RequestHandler.Builder builder = new RequestHandler.Builder();
builder.addHandler(new Commander())
.addHandler(new Officer())
.addHandler(new Soldier());
chain = builder.build();
}
框架源码分析
上文中自己实现了责任链模式,在很多的开源框架中也在大量的使用责任链模式。本小节,结合三种开源代码对于责任链的实现,进一步加深对责任链模式的理解和领悟。
当然责任链模式在开源框架中的实现绝不仅仅只有这三种,其他类似与Spring等框架也都在大量使用,大家可以按照实际的需求具体分析。
Servlet源码servlet包中有Filter接口,其中的doFilter使用了FilterChain,从名称上我们也可以看出实现了一个过滤链。
public interface Filter {
// 省去无关代码
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException;
// 省去无关代码
}
servlet仅仅定义了FilterChain的接口,具体的实现开放给具体的适用方。
package javax.servlet;
import java.io.IOException;
/**
* A FilterChain is an object provided by the servlet container to the developer
* giving a view into the invocation chain of a filtered request for a resource. Filters
* use the FilterChain to invoke the next filter in the chain, or if the calling filter
* is the last filter in the chain, to invoke the resource at the end of the chain.
*
* @see Filter
* @since Servlet 2.3
**/
public interface FilterChain {
/**
* Causes the next filter in the chain to be invoked, or if the calling filter is the last filter
* in the chain, causes the resource at the end of the chain to be invoked.
*
* @param request the request to pass along the chain.
* @param response the response to pass along the chain.
*/
public void doFilter ( ServletRequest request, ServletResponse response ) throws IOException, ServletException;
}
以jettey包中的ServletHandler的实现为例,继续介绍FilterChain的实现。
public void doFilter(ServletRequest request, ServletResponse response)
throws IOException, ServletException
{
final Request baseRequest=Request.getBaseRequest(request);
// pass to next filter
if (_filterHolder!=null)
{
if (LOG.isDebugEnabled())
LOG.debug("call filter {}", _filterHolder);
Filter filter= _filterHolder.getFilter();
//if the request already does not support async, then the setting for the filter
//is irrelevant. However if the request supports async but this filter does not
//temporarily turn it off for the execution of the filter
if (baseRequest.isAsyncSupported() && !_filterHolder.isAsyncSupported())
{
try
{
baseRequest.setAsyncSupported(false,_filterHolder.toString());
filter.doFilter(request, response, _next);
}
finally
{
baseRequest.setAsyncSupported(true,null);
}
}
else
filter.doFilter(request, response, _next);
return;
}
// Call servlet
HttpServletRequest srequest = (HttpServletRequest)request;
if (_servletHolder == null)
notFound(baseRequest, srequest, (HttpServletResponse)response);
else
{
if (LOG.isDebugEnabled())
LOG.debug("call servlet " _servletHolder);
_servletHolder.handle(baseRequest,request, response);
}
}
通过分析ServletHandler中doFilter方法的引用可以看出,doFilter被不同的Handler实现.
最终我们可以找到FilterChain的具体实现类VirtualFilterChain:
private static class VirtualFilterChain implements FilterChain {
private final FilterChain originalChain;
private final List<? extends Filter> additionalFilters;
private int currentPosition = 0;
public VirtualFilterChain(FilterChain chain, List<? extends Filter> additionalFilters) {
this.originalChain = chain;
this.additionalFilters = additionalFilters;
}
@Override
public void doFilter(final ServletRequest request, final ServletResponse response)
throws IOException, ServletException {
if (this.currentPosition == this.additionalFilters.size()) {
this.originalChain.doFilter(request, response);
}
else {
this.currentPosition ;
Filter nextFilter = this.additionalFilters.get(this.currentPosition - 1);
nextFilter.doFilter(request, response, this);
}
}
}
VirtualFilterChain是将所有的Filter存储在additionalFilters的集合中。从doFilter作为入口,开始责任链的传递和工作。
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
new VirtualFilterChain(chain, this.filters).doFilter(request, response);
}
在Netty中有一个典型的责任链实现ChannelPipeline。具体的链路如下:
* <pre>
* I/O Request
* via {@link Channel} or
* {@link ChannelHandlerContext}
* |
* --------------------------------------------------- ---------------
* | ChannelPipeline | |
* | |/ |
* | --------------------- ----------- ---------- |
* | | Inbound Handler N | | Outbound Handler 1 | |
* | ---------- ---------- ----------- ---------- |
* | /|\ | |
* | | |/ |
* | ---------- ---------- ----------- ---------- |
* | | Inbound Handler N-1 | | Outbound Handler 2 | |
* | ---------- ---------- ----------- ---------- |
* | /|\ . |
* | . . |
* | ChannelHandlerContext.fireIN_EVT() ChannelHandlerContext.OUT_EVT()|
* | [ method call] [method call] |
* | . . |
* | . |/ |
* | ---------- ---------- ----------- ---------- |
* | | Inbound Handler 2 | | Outbound Handler M-1 | |
* | ---------- ---------- ----------- ---------- |
* | /|\ | |
* | | |/ |
* | ---------- ---------- ----------- ---------- |
* | | Inbound Handler 1 | | Outbound Handler M | |
* | ---------- ---------- ----------- ---------- |
* | /|\ | |
* --------------- ----------------------------------- ---------------
* | |/
* --------------- ----------------------------------- ---------------
* | | | |
* | [ Socket.read() ] [ Socket.write() ] |
* | |
* | Netty Internal I/O Threads (Transport Implementation) |
* -------------------------------------------------------------------
* </pre>
ChannelHandler是Netty提供的默认处理者。典型的实现是ChannelInboundHandler和ChannelOutboundHandler。
public interface ChannelHandler {
/**
* Gets called after the {@link ChannelHandler} was added to the actual context and it's ready to handle events.
*/
void handlerAdded(ChannelHandlerContext ctx) throws Exception;
/**
* Gets called after the {@link ChannelHandler} was removed from the actual context and it doesn't handle events
* anymore.
*/
void handlerRemoved(ChannelHandlerContext ctx) throws Exception;
/**
* Gets called if a {@link Throwable} was thrown.
*
* @deprecated if you want to handle this event you should implement {@link ChannelInboundHandler} and
* implement the method there.
*/
@Deprecated
void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception;
/**
* Indicates that the same instance of the annotated {@link ChannelHandler}
* can be added to one or more {@link ChannelPipeline}s multiple times
* without a race condition.
* <p>
* If this annotation is not specified, you have to create a new handler
* instance every time you add it to a pipeline because it has unshared
* state such as member variables.
* <p>
* This annotation is provided for documentation purpose, just like
* <a href="http://www.javaconcurrencyinpractice.com/annotations/doc/">the JCIP annotations</a>.
*/
@Inherited
@Documented
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@interface Sharable {
// no value
}
}
ChannelPipeline可以看做是整个处理任务的chain管理者,netty提供的的默认实现DefaultChannelPipeline如下。
public class DefaultChannelPipeline implements ChannelPipeline {
static final InternalLogger logger = InternalLoggerFactory.getInstance(DefaultChannelPipeline.class);
private static final String HEAD_NAME = generateName0(HeadContext.class);
private static final String TAIL_NAME = generateName0(TailContext.class);
private static final FastThreadLocal<Map<Class<?>, String>> nameCaches =
new FastThreadLocal<Map<Class<?>, String>>() {
@Override
protected Map<Class<?>, String> initialValue() {
return new WeakHashMap<Class<?>, String>();
}
};
private static final AtomicReferenceFieldUpdater<DefaultChannelPipeline, MessageSizeEstimator.Handle> ESTIMATOR =
AtomicReferenceFieldUpdater.newUpdater(
DefaultChannelPipeline.class, MessageSizeEstimator.Handle.class, "estimatorHandle");
final AbstractChannelHandlerContext head;
final AbstractChannelHandlerContext tail;
private final Channel channel;
private final ChannelFuture succeededFuture;
private final VoidChannelPromise voidPromise;
private final boolean touch = ResourceLeakDetector.isEnabled();
private Map<EventExecutorGroup, EventExecutor> childExecutors;
private volatile MessageSizeEstimator.Handle estimatorHandle;
private boolean firstRegistration = true;
/**
* This is the head of a linked list that is processed by {@link #callHandlerAddedForAllHandlers()} and so process
* all the pending {@link #callHandlerAdded0(AbstractChannelHandlerContext)}.
*
* We only keep the head because it is expected that the list is used infrequently and its size is small.
* Thus full iterations to do insertions is assumed to be a good compromised to saving memory and tail management
* complexity.
*/
private PendingHandlerCallback pendingHandlerCallbackHead;
/**
* Set to {@code true} once the {@link AbstractChannel} is registered.Once set to {@code true} the value will never
* change.
*/
private boolean registered;
protected DefaultChannelPipeline(Channel channel) {
this.channel = ObjectUtil.checkNotNull(channel, "channel");
succeededFuture = new SucceededChannelFuture(channel, null);
voidPromise = new VoidChannelPromise(channel, true);
tail = new TailContext(this);
head = new HeadContext(this);
head.next = tail;
tail.prev = head;
}
在bt中初始化处理的工厂类中,按照如下方式构建了责任链。
public class TorrentProcessorFactory implements ProcessorFactory {
private Map<Class<?>, Processor<?>> processors() {
Map<Class<?>, Processor<?>> processors = new HashMap<>();
processors.put(TorrentContext.class, createTorrentProcessor());
processors.put(MagnetContext.class, createMagnetProcessor());
return processors;
}
protected ChainProcessor<TorrentContext> createTorrentProcessor() {
ProcessingStage<TorrentContext> stage5 = new SeedStage<>(null, torrentRegistry);
ProcessingStage<TorrentContext> stage4 = new ProcessTorrentStage<>(stage5, torrentRegistry, trackerService, eventSink);
ProcessingStage<TorrentContext> stage3 = new ChooseFilesStage<>(stage4, torrentRegistry, assignmentFactory, config);
ProcessingStage<TorrentContext> stage2 = new InitializeTorrentProcessingStage<>(stage3, connectionPool,
torrentRegistry, dataWorker, bufferedPieceRegistry, manualControlService, eventSink, config);
ProcessingStage<TorrentContext> stage1 = new CreateSessionStage<>(stage2, torrentRegistry, eventSource,
connectionSource, messageDispatcher, messagingAgents, config);
ProcessingStage<TorrentContext> stage0 = new FetchTorrentStage(stage1, eventSink);
return new ChainProcessor<>(stage0, executor, new TorrentContextFinalizer<>(torrentRegistry, eventSink));
}
protected ChainProcessor<MagnetContext> createMagnetProcessor() {
ProcessingStage<MagnetContext> stage5 = new SeedStage<>(null, torrentRegistry);
ProcessingStage<MagnetContext> stage4 = new ProcessMagnetTorrentStage(stage5, torrentRegistry, trackerService, eventSink);
ProcessingStage<MagnetContext> stage3 = new ChooseFilesStage<>(stage4, torrentRegistry, assignmentFactory, config);
ProcessingStage<MagnetContext> stage2 = new InitializeMagnetTorrentProcessingStage(stage3, connectionPool,
torrentRegistry, dataWorker, bufferedPieceRegistry, manualControlService, eventSink, config);
ProcessingStage<MagnetContext> stage1 = new FetchMetadataStage(stage2, metadataService, torrentRegistry,
peerRegistry, eventSink, eventSource, config);
ProcessingStage<MagnetContext> stage0 = new CreateSessionStage<>(stage1, torrentRegistry, eventSource,
connectionSource, messageDispatcher, messagingAgents, config);
return new ChainProcessor<>(stage0, executor, new TorrentContextFinalizer<>(torrentRegistry, eventSink));
}
BT定义的抽象处理者(Handler)角色为ProcessingStage。使用after()表示next。
package bt.processor;
import bt.processor.listener.ProcessingEvent;
/**
* @param <C> Type of processing context
* @since 1.3
*/
public interface ProcessingStage<C extends ProcessingContext> {
/**
* @return Type of event, that should be triggered after this stage has completed.
* @since 1.5
*/
ProcessingEvent after();
/**
* @param context Processing context
* @return Next stage
* @since 1.3
*/
ProcessingStage<C> execute(C context);
}
具体的链式调用实现。由process方法调用executeStage,当存在next节点后,继续调用executeStage。直到链路调用结束。
@Override
public CompletableFuture<?> process(C context, ListenerSource<C> listenerSource) {
Runnable r = () -> executeStage(chainHead, context, listenerSource);
return CompletableFuture.runAsync(r, executor);
}
private void executeStage(ProcessingStage<C> chainHead,
C context,
ListenerSource<C> listenerSource) {
ProcessingEvent stageFinished = chainHead.after();
Collection<BiFunction<C, ProcessingStage<C>, ProcessingStage<C>>> listeners;
if (stageFinished != null) {
listeners = listenerSource.getListeners(stageFinished);
} else {
listeners = Collections.emptyList();
}
ProcessingStage<C> next = doExecute(chainHead, context, listeners);
if (next != null) {
executeStage(next, context, listenerSource);
}
}
没有任何一种设计模式是万能的,所有的模式都需要结合实际使用。本章节将综合介绍下责任链模式的优缺点。
优点- 将请求与处理解耦。
- 请求处理者(节点对象)只需要关注自己感兴趣的请求进行处理即可,对于不感兴趣的请求,直接转发给下一级的next节点对象即可。
- 具备链式传递处理请求功能,请求发送者无需知晓链路结构,只需等待请求在最终链路处理完成后的处理结果。
- 链路结构灵活,可以通过改变链路结构动态地新增或删除责任的具体节点。
- 易于扩展新的请求处理能力,符合设计模式的开闭原则。
- 责任链太长或者处理时间过长,会影响整体性能。
- 如果节点对象存在循环引用时,会造成死循环,导致系统崩溃。
设计模式可以使得代码更加优雅,增强代码的扩展性。但是万万不能为了设计模式而设计模式,如果真的这样做了,反而会适得其反,画蛇添足,大幅度增加代码复杂度和降低可维护性。只有在充分的分析业务场景、代码结构的前提下合理的使用设计模式,才能发挥出设计模式最大的作用。
最后一句:设计模式是道法,并不是术法。理解内涵最为重要。
,