Chain of Responsibility

The chain of responsibility design pattern is known as a behavioral pattern consisting of client objects and a series of handler objects. It provides more than one object the opportunity to handle a request by linking receivers together (see left UML diagram). Instead of having one monolithic class, as I have or coupling your code to each and every concrete class, with the chain of responsibility pattern, you can avoid both.

Refactoring Rotation Controller

On the right is the UML diagram for handling user inputs in my game. The ControlListener implements the Java AWT Event KeyListener. The ControlListener listens for various keyboard actions (UP_ARROW – rotate clockwise, DOWN_ARROW – drop, LEFT_ARROW – move left, RIGHT_ARROW – move right, Q – rotate counter-clockwise, and W – rotate clockwise). When user presses UP_ARROW, Q, or W, it will create an instance of RotateController class to handle the respective rotation action. On the original UML diagram, you can see the long list of private methods I’ve implemented to handle the rotation action for various tetris shapes.

On the left is the refactored UML diagram with the rotation logic implemented using the chain of responsibility design pattern. Gone are the many private methods created to handle every possible shapes. For each shape, we now have a respective handler class responsible for rotating the shape. The chain of these rotation handler will check if can handle the rotation request by inspecting the shape associated with the request.

public Coordinate[] executeRequest(RotateRequest request) {
  final Coordinate[] coordinate;
  final IShape shape = request.getShape();
  final Rotate rotate = request.getRotate();

  if( shape.getShape() == this.getShape()) {
    coordinate = getTargetCoordinates(shape, rotate);
  } else {
    if(this.nextHandler == null) {
      throw new HandlerNotFoundException("No handler defined for " + shape.getShape());
    } else {
      coordinate = this.nextHandler.executeRequest(request);
    }
  }

  return coordinate;
}

If it cannot handle the request, it will pass the request to the next handler. If it reaches the end of the chain and no handler is found, a runtime exception will be thrown. Feel free to browse the final code base on GitHub.

SharePoint API
Several years ago, I wrote a SharePoint API in Java to interact with its List Soap Service. This soap service had a feature to query the target list using Collaborative Application Markup Language (CAML). Here’s an example of CAML query to filter the task list where the TaskName is “Foo Bar” and the Status is “In Progress”.

<query>
  <where>
    <and>
      <eq>
        <fieldref name="TaskName">
        <value type="Text">Foo Bar</value>
      </fieldref></eq>
      <eq>
        <fieldref name="Status">
        <value type="Text">In Progress</value>
      </fieldref></eq>
    </and>
   </where>
</query>

As part of this SharePoint API, I had written a corresponding set of Java classes – each node represented by a class. For trivial query like above, it would look like the following:

final Expression leftExpression = new Equals(new Field("TaskName", "Foo Bar"));
final Expression rightExpression = new Equals(new Field("Status", "In Progress"));
final Condition condition = new And(leftExpression, rightExpression);
final Where clause = new Where(condition);
final Query query = new Query(clause);

As you can predict, for complicated scenarios, this would quickly become unreadable. By applying the concept of Fluent Interface, we can make it far more readable. For example, the above become the following:

final Where clause =
  new Where(
    and(eq("TaskName", "Foo Bar"),
        eq("Status", "In Progress")));

Applying Fluent Interface
A good Fluent Interface takes a while to build. It should be built with the goal of readability and flow in mind. Return type should be chosen based on what you need to continue fluent action. Here’s the SharePoint API implementation. For the complete implementation, please see GitHub Source.

.
.
.
public static Condition and(Expression left, Expression right) {
  return new And(left, right);
}

public static Condition and(Expression left, Condition right) {
  return new And(left, right);
}

public static Condition and(Condition left, Expression right) {
  return new And(left, right);
}

public static Condition and(Condition left, Condition right) {
  return new And(left, right);
}
.
.
.
public static Expression eq(Field field) {
  return new Equals(field);
}

For complicated scenarios where you want to get all task assigned to John with status in “New” or “In Progress” and task created after Jan 1, 2014, the CAML would like the following.

<query>
  <where>
    <and>
      <eq>
        <fieldref name="AssignedTo">
        <value type="Text">John</value>
      </fieldref></eq>
      <and>
        <or>
          <eq>
            <fieldref name="Status">
            <value type="Text">New</value>
          </fieldref></eq>
          <eq>
            <fieldref name="Status">
            <value type="Text">In Progress</value>
          </fieldref></eq>
        </or>
        <gt>
          <fieldref name="CreateDate">
          <value type="DateTime">2014-01-01T00:00:00Z</value>
        </fieldref></gt>
    </and>
   </and></where>
</query>

Here’s the same in Fluent Interface

final Where clause =
  new Where(
    and(eq("AssignedTo", "John"),
    and(
      or(eq("Status", "New"),
         eq("Status", "In Progress")),
      gt("CreateDate", "2014-01-01T00:00:00Z"))));