Article: Introduction to Chain of Responsibility

An excerpt from http://www.sitepoint.com/introduction-to-chain-of-responsibility/, by Nicola Pietroluongo

In this article, we’ll explain and demonstrate the Chain of Responsibility pattern.

Definition

The Chain of Responsibility is a behavioral design pattern that processes a request through a series of processor (handlers/receivers) objects. The request is sent from one handler object to another and processed by one (pure implementation) or all of the handlers. All the handlers are part of the chain.

Two simple examples containing a chain logic are:

  • a person using an ATM to get cash, (enter pin, amount, receipt);
  • a help desk call (options list, press dial buttons, follow the steps).

Participants

The pattern in the short version includes:

  • The Handler: defines an interface for handling requests. It can be an abstract class, which optionally implements default methods and the way to set a successor in the chain.
  • Many concrete handler objects: process the request and optionally provide access to successors;

CoR can also include:

  • a Client object to perform the request and set up the chain;
  • a Request object;
  • a Response object;
  • other design patterns.

The CoR design pattern is not one that is used often, but its core logic makes it useful in several cases.

CoR is useful when:

  • the handler must be determined automatically (e.g., a logging system);
  • the handler cannot be known in advance (e.g., handling exceptions);
  • the request must pass through a specific chain’s priority (e.g., event propagation, command propagation) or the order of the chain must be dynamic.

Basic usage

CoR is often applied in conjunction with Composite pattern, so it’s easy to treat all the handlers in the same way and dispatch the request to the chain’s successors.
Below is a basic PHP example:

<?php
abstract class BasicHandler
{
    /**
     * @var Handler
     */
    private $successor = null;

    /**
     * Sets a successor handler.
     * 
     * @param Handler $handler
     */
    public function setSuccessor(Handler $handler)
    {
        $this->successor = $handler;
    }

    /**
     * Handles the request and/or redirect the request
     * to the successor.
     *
     * @param mixed $request
     *
     * @return mixed
     */
    abstract public function handle($request);

}

Below is an example (not fully implemented) continuing with the code above:

class FirstHandler extends BasicHandler
{
    public function handle($request)
    {
        //provide a response, call the next successor
    }
}
 
// .. code for SecondHandler and ThirdHandler classes ..
 
$firstHandler = new FirstHandler();
$secondHandler = new SecondHandler();
$thirdHandler = new ThirdHandler();
 
$firstHandler->setSuccessor($secondHandler);
$secondHandler->setSuccessor($thirdHandler);
 
$result = $firstHandler->handle($request);

Continue reading this article on SitePoint!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.