Chain of Responsibility Pattern

As the name suggests, the Chain of Responsibility Pattern creates a chain of receiver objects for a request. This pattern decouples the sender and receiver of a request based on the type of request. This type of design pattern falls under behavioral patterns.

In this pattern, typically each receiver contains a reference to another receiver. If one object cannot handle the request, it passes the same request to the next receiver, and so on.

Introduction

Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Main Solution: The handlers in the chain are responsible for processing requests. The client only needs to send the request to the chain, without needing to be concerned with the details of request processing or its propagation. Thus, the chain decouples the sender and the processor of the request.

When to Use: When processing messages requires filtering through multiple stages.

How to Solve: All intercepting classes implement a common interface.

Key Code: The Handler aggregates itself, and within HandlerRequest, it checks if the conditions are met. If not, it passes the request to the next handler, which is set beforehand.

Example Applications: 1. "Hot Potato" in Dream of the Red Chamber.

2. Event bubbling in JavaScript.
3. Encoding handling in Apache Tomcat for JAVA WEB, interceptors in Struts2, and filters in JSP Servlet.

Advantages: 1. Reduces coupling. It decouples the sender and receiver of a request.

2. Simplifies objects. The object does not need to know the chain structure.
3. Increases flexibility in assigning responsibilities to objects. Responsibilities can be added or removed dynamically by changing members within the chain or their order.
4. It is easy to add new request processing classes.

Disadvantages: 1. There is no guarantee that the request will be handled.

2. System performance may be affected, and debugging can be inconvenient, potentially leading to cyclic calls.
3. Runtime characteristics may be difficult to observe, hindering debugging.

Usage Scenarios: 1. Multiple objects can handle the same request, with the specific handler determined automatically at runtime.

2. Submitting a request to one of multiple objects without explicitly specifying the receiver.
3. Dynamically specifying a group of objects to handle the request.

Notes: Commonly encountered in JAVA WEB applications.

Implementation

We create an abstract class AbstractLogger with detailed logging levels. Then we create three types of loggers that extend AbstractLogger. Each logger checks if the message level is appropriate for itself; if so, it prints the message; otherwise, it passes the message to the next logger.

Step 1

Create an abstract logger class.

AbstractLogger.java

public abstract class AbstractLogger {
   public static int INFO = 1;
   public static int DEBUG = 2;
   public static int ERROR = 3;

   protected int level;

   // Next element in the chain of responsibility
   protected AbstractLogger nextLogger;

   public void setNextLogger(AbstractLogger nextLogger){
      this.nextLogger = nextLogger;
   }

   public void logMessage(int level, String message){
      if(this.level <= level){
         write(message);
      }
      if(nextLogger != null){
         nextLogger.logMessage(level, message);
      }
   }

   abstract protected void write(String message);
}

Step 2

Create concrete classes that extend the logger class.

ConsoleLogger.java

public class ConsoleLogger extends AbstractLogger {

   public ConsoleLogger(int level){
      this.level = level;
   }

   @Override
   protected void write(String message) {    
      System.out.println("Standard Console::Logger: " + message);
   }
}

ErrorLogger.java

public class ErrorLogger extends AbstractLogger {

   public ErrorLogger(int level){
      this.level = level;
   }

   @Override
   protected void write(String message) {    
      System.out.println("Error Console::Logger: " + message);
   }
}

FileLogger.java

public class FileLogger extends AbstractLogger {

   public FileLogger(int level){
      this.level = level;
   }

   @Override
   protected void write(String message) {    
      System.out.println("File::Logger: " + message);
   }
}

Step 3

Create different types of loggers, assign them different error levels, and set the next logger in each. The next logger in each represents a part of the chain.

ChainPatternDemo.java

public class ChainPatternDemo {

   private static AbstractLogger getChainOfLoggers(){

      AbstractLogger errorLogger = new ErrorLogger(AbstractLogger.ERROR);
      AbstractLogger fileLogger = new FileLogger(AbstractLogger.DEBUG);
      AbstractLogger consoleLogger = new ConsoleLogger(AbstractLogger.INFO);

      errorLogger.setNextLogger(fileLogger);
      fileLogger.setNextLogger(consoleLogger);

      return errorLogger;  
   }

   public static void main(String[] args) {
      AbstractLogger loggerChain = getChainOfLoggers();

      loggerChain.logMessage(AbstractLogger.INFO, "This is an information.");

      loggerChain.logMessage(AbstractLogger.DEBUG, 
         "This is a debug level information.");

      loggerChain.logMessage(AbstractLogger.ERROR, 
         "This is an error information.");
   }
}

Step 4

Execute the program, output results:

Standard Console::Logger: This is an information.
File::Logger: This is a debug level information.
Standard Console::Logger: This is a debug level information.
Error Console::Logger: This is an error information.
File::Logger: This is an error information.
Standard Console::Logger: This is an error information.