Samiksha Jaiswal (Editor)

Chain of responsibility pattern

Updated on
Edit
Like
Comment
Share on FacebookTweet on TwitterShare on LinkedInShare on Reddit

In object-oriented design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.

Contents

In a variation of the standard chain-of-responsibility model, some handlers may act as dispatchers, capable of sending commands out in a variety of directions, forming a tree of responsibility. In some cases, this can occur recursively, with processing objects calling higher-up processing objects with commands that attempt to solve some smaller part of the problem; in this case recursion continues until the command is processed, or the entire tree has been explored. An XML interpreter might work in this manner.

This pattern promotes the idea of loose coupling.

Java example

Below is an example of this pattern in Java. In this example we have different roles, each having a fixed purchasing limit and a successor. Every time a user in a role receives a purchase request that exceeds his or her limit, the request is passed to his or her successor.

The PurchasePower abstract class with the abstract method processRequest.

Four implementations of the abstract class above: Manager, Director, Vice President, President

The following code defines the PurchaseRequest class that keeps the request data in this example.

In the following usage example, the successors are set as follows: Manager -> Director -> Vice President -> President

C# example

This C# examples uses the logger application to select different sources based on the log level;

Crystal example

Output

Writing to console: Entering function ProcessOrder(). Writing to console: Order record retrieved. Writing to console: Customer Address details missing in Branch DataBase. Writing to Log File: Customer Address details missing in Branch DataBase. Writing to console: Customer Address details missing in Organization DataBase. Writing to Log File: Customer Address details missing in Organization DataBase. Writing to console: Unable to Process Order ORD1 Dated D1 For Customer C1. Sending via email: Unable to Process Order ORD1 Dated D1 For Customer C1. Writing to console: Order Dispatched. Sending via email: Order Dispatched.

Cocoa and Cocoa Touch

The Cocoa and Cocoa Touch frameworks, used for OS X and iOS applications respectively, actively use the chain-of-responsibility pattern for handling events. Objects that participate in the chain are called responder objects, inheriting from the NSResponder (OS X)/UIResponder (iOS) class. All view objects (NSView/UIView), view controller objects (NSViewController/UIViewController), window objects (NSWindow/UIWindow), and the application object (NSApplication/UIApplication) are responder objects.

Typically, when a view receives an event which it can't handle, it dispatches it to its superview until it reaches the view controller or window object. If the window can't handle the event, the event is dispatched to the application object, which is the last object in the chain. For example:

  • On OS X, moving a textured window with the mouse can be done from any location (not just the title bar), unless on that location there's a view which handles dragging events, like slider controls. If no such view (or superview) is there, dragging events are sent up the chain to the window which does handle the dragging event.
  • On iOS, it's typical to handle view events in the view controller which manages the view hierarchy, instead of subclassing the view itself. Since a view controller lies in the responder chain after all of its managed subviews, it can intercept any view events and handle them.
  • References

    Chain-of-responsibility pattern Wikipedia