Chain of Responsibility design pattern

This is one of the behavioral patterns which comes quite handy. This pattern specifies the way in which components interact with each other and that it is categorized in behavioral patterns.

As the name suggests this patterns is useful when there is a chain of business logic units which should be applied on a piece of data. There are several demonstrations of this pattern which is utilized by many popular frameworks and libraries. For instance, security filter chain in spring security is a clear and awesome implementation of this pattern which applies several security constraints on a request sent from the client.

The general idea of this design pattern is that if the request (or the piece of data which should be processed) is successfully processed by current component of the chain then it should be passed to the next component, otherwise some exception should be thrown or some error-handling policy should be provided.

Here I go through a simple example of this pattern. This sample imitates the security filter chain of spring security in a simple form and tries to process the request throughout a chain of filters.

Based on the class diagram, there is an interface defining a contract which every request handler should implement. It has two methods, setNext(Handler handler) which sets the next handler of the chain and execute(Request request) which performs the business logic.

AbstractHandler class implements Handler interface and provides an implementation of setNext method. The other method of Handler class is not implemented since it is expected to be implemented by a concrete class.

ValidationHandler, AuthenticationHandler and AuthorizationHandler are the concrete classes which provides specific implementations for execute method of Handler interface. As the name shows, Request instance gets validated in ValidationHandler, the user/client which has sent the request gets authenticated in authentication handler and finally the request gets authorized to check if they have access to the requested resource in AuthorizationHandler.

An important point about the handler concrete classes is that their order in the chain can be set in runtime and in our example the first handler is the ValidationHandler, second one is the AuthenticationHandler and last one is AuthorizationHandler.

Finally, there are two value classes, first one is Request class which simulates a http request sent by a client and User class which holds the data of authenticated users, actually it plays the role of a datasource which provides registered users.

The Demo class contains several tests to show how the request is processed by the handlers.