Shulou(Shulou.com)06/02 Report--

This article focuses on "the implementation of the chain of responsibility pattern in the Java design pattern". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "the implementation of the chain of responsibility pattern in the Java design pattern".

Design pattern-responsibility chain pattern

The chain of responsibility pattern (Chain of Responsibility Pattern) is a behavioral design pattern that creates a chain of processing objects for requests. Each node in the chain is regarded as an object, each node handles different requests, and a next node object is automatically maintained internally. When a request is made from the head of the chain, it is passed to each node object in turn along the path of the chain until an object processes the request.

The responsibility chain model mainly solves the decoupling of the process of initiating the request and specific processing of the request, the processor on the responsibility chain is responsible for handling the request, and the user only needs to send the request to the responsibility chain without paying attention to the processing details and delivery of the request.

The realization of responsibility chain Model

The implementation of the responsibility chain pattern mainly has four elements: the processor abstract class, the concrete processor implementation class, saving the processor information, and processing the execution.

Pseudo code example:

/ / * Storage in collection form is similar to filters in tomcat *

/ / processor abstract class

Class AbstractHandler {void doHandler (Object arg0)}

/ / processor concrete implementation class

Class Handler1 extends AbstractHandler {assert coutine;}

Class Handler2 extends AbstractHandler {assert coutine;}

Class Handler3 extends AbstractHandler {assert coutine;}

/ / create a set and store all processor instance information

List handlers = new List ()

Handlers.add (handler1, handler2, handler3)

/ / process the request and call the processor

Void process (request) {

For (handler in handlers) {

Handler.doHandler (request)

}

}

/ / initiate the request call and process the request through the responsibility chain

Call.process (request)

/ / * usage in calling netty in linked list form *

/ / processor abstract class

Class AbstractHandler {

Next node of AbstractHandler next;//

Void doHandler (Object arg0)

}

/ / processor concrete implementation class

Class Handler1 extends AbstractHandler {assert coutine;}

Class Handler2 extends AbstractHandler {assert coutine;}

Class Handler3 extends AbstractHandler {assert coutine;}

/ / string processors into linked lists to store

Pipeline = head [handler1-> handler2-> handler3] tail

/ / process the request and call the processor from beginning to end

Void process (request) {

Handler = pipeline.findOne; / / find the first one

While (handler! = null) {

Handler.doHandler (request)

Handler = handler.next

}

}

A concrete code example of a chain of responsibility implementation in the form of a linked list:

/ / usage in calling netty in linked list form

Public class PipelineDemo {

/ / create a head during initialization as the beginning of the chain of responsibility, but there is no specific processing

Public HandlerChainContext head =

New HandlerChainContext (

New AbstractHandler () {

@ Override

Void doHandler (HandlerChainContext handlerChainContext, Object arg0) {

HandlerChainContext.runNext (arg0)

}

});

Public void processRequest (Object arg0) {

This.head.handler (arg0)

}

Public void addLast (AbstractHandler handler) {

HandlerChainContext context = head

While (context.next! = null) {

Context = context.next

}

Context.next = new HandlerChainContext (handler)

}

Public static void main (String [] args) {

PipelineDemo pipelineChainDemo = new PipelineDemo ()

PipelineChainDemo.addLast (new Handler2 ())

PipelineChainDemo.addLast (new Handler1 ())

PipelineChainDemo.addLast (new Handler1 ())

PipelineChainDemo.addLast (new Handler2 ())

/ / initiate a request

PipelineChainDemo.processRequest ("Train Woo")

}

}

/ / handler context, I am mainly responsible for chain maintenance and chain execution

Class HandlerChainContext {

HandlerChainContext next; / / next node

AbstractHandler handler

Public HandlerChainContext (AbstractHandler handler) {

This.handler = handler

}

Void handler (Object arg0) {

This.handler.doHandler (this, arg0)

}

/ / continue to the next

Void runNext (Object arg0) {

If (this.next! = null) {

This.next.handler (arg0)

}

}

}

/ / processor abstract class

Abstract class AbstractHandler {

/ / processor

Abstract void doHandler (HandlerChainContext handlerChainContext, Object arg0)

}

/ / processor concrete implementation class

Class Handler1 extends AbstractHandler {

@ Override

Void doHandler (HandlerChainContext handlerChainContext, Object arg0) {

Arg0 = arg0.toString () + ".. the small tail of handler 1."

System.out.println ("I am an instance of Handler1, I am dealing with:" + arg0)

/ / continue to the next

HandlerChainContext.runNext (arg0)

}

}

/ / processor concrete implementation class

Class Handler2 extends AbstractHandler {

@ Override

Void doHandler (HandlerChainContext handlerChainContext, Object arg0) {

Arg0 = arg0.toString () + ".. the little tail of handler 2."

System.out.println ("I am an instance of Handler2, I am dealing with:" + arg0)

/ / continue to the next

HandlerChainContext.runNext (arg0)

}

}

/ / output result: I am an example of Handler2, I am dealing with: the small tail of the train purr ~. Handler 2.

I'm an example of Handler1, and I'm dealing with: the train whine. Handler 2's tail. Handler 1's tail.

I am an example of Handler1, and I am dealing with: the little tail of the train, the tail of handler 2, the tail of handler, the tail of handler.

I'm an example of Handler2, and I'm dealing with: the train whine. Handler 2's tail. Handler 1's tail. Handler 1's tail. Handler 2's tail. ChannelPipeline chain of responsibility in Netty

The pipeline pipeline holds all the processor information of the channel, and a proprietary pipeline is automatically created when the channel is created. Inbound and outbound events call the processors on the pipeline.

Inbound and outbound events

Inbound event: usually means that the IO thread generates inbound data

(popular understanding: events that come up from the bottom of socket are inbound.)

For example, when EventLoop receives the OP_READ event of selector, and the inbound processor calls socketChannel.read (ByteBuffer) to receive the data, this will cause the next channelRead method contained in the ChannelPipeline of the channel to be called.

Outbound event: usually means that the IO thread performs the actual output operation

(popular understanding: events that want to actively operate at the bottom of socket are outbound.)

For example, the bind method is intended to request server socket to bind to a given SocketAddress, which will cause the bind method in the next outbound processor contained in the ChannelPipeline of the channel to be called

Handler in Pipeline

ChannelHandler: used to handle IO events or intercept IO actions and forward them to the next processor in ChannelPipeline. This top-level interface definition is very weak, and the following two major subinterfaces are implemented when events are used: ChannelInBoundHandler, which handles inbound IO events, and ChannelOutBoundHandler, which handles outbound IO events.

Adapter: for the convenience of development and avoiding all handler to implement interface methods once, Netty provides a simple implementation class:

ChannelInBoundHandlerAdapter handles inbound IO events

ChannelOutBoundHandlerAdapter handles outbound IO events

ChannelDuplexHandler supports handling both inbound and outbound events

ChannelHandlerContext: the object actually stored in the Pipeline is not the ChannelHandler, but the context object, which wraps the handler in the context object, passes events up or down, or modifies the pipeline through the context ChannelPipeline interaction.

ChannelPipeline is thread-safe and ChannelHandler can be added or removed at any time.

For example, you can insert an encryption handler when sensitive information is about to be exchanged and delete it after the exchange.

General operation, added to the initialization, less deleted.

API for managing handler in Pipeline:

Implementation Analysis of handler

Analyze the handling of register inbound events

Analyze the handling of bind outbound events

Analyze the handling of accept inbound events

Analyze the handling of read inbound events

Summary

The user has one or more channelhandler in the pipeline to accept IO events and request IO actions

A typical server will have the following handlers in the pipeline of each channel, but may vary depending on the complexity and characteristics of the protocol and business logic:

Protocol Decoder-converts binary data to Java objects

Protocol Encoder-converts Java objects to binary data

Business logic processor-executes the actual business logic

The application of responsibility chain mode ensures the high scalability of Netty.

At this point, I believe you have a deeper understanding of "the implementation of the chain of responsibility pattern in the Java design pattern". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.