Decorator Pattern

The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It is easy to add functionality to an entire class of objects by subclassing an object, but it is impossible to extend a single object this way. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified.

Decorator, also known as a Wrapper, is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility, since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.

It is a good idea to use a Decorator in a situation where you want to change the behaviour of an object repeatedly (by adding and subtracting functionality) during runtime.

Example :-A very nice example of decorators is Java's I/O stream implementation.

Chain of Responsibility

Chain of Responsibility is a popular technique for organizing the execution of complex processing flows. It is not difficult if you want to write it yourself but Commons Chain has already implemented this pattern for you.

Commons Chain models a computation as a series of "commands" that can be combined into a "chain". The API for a command consists of a single method (execute()), which is passed a "context" parameter containing the dynamic state of the computation, and whose return value is a boolean that determines whether or not processing for the current chain has been completed (true), or whether processing should be delegated to the next command in the chain (false).

E.g., first I create my custom context to be passed around my flows.

import org.apache.commons.chain.impl.ContextBase;

public class MyContext extends ContextBase {
  private String name;
  private String email;

  public String getName() {
      return name;
  }

  public void setName(String name) {
      this.name = name;
  }

  public String getEmail() {
      return email;
  }

  public void setEmail(String email) {
      this.email = email;
  }
}

Then I created my processes, each one as a command.

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command1 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("First command");
      MyContext myContext = (MyContext)context;
      myContext.setName("twit88");
      return false;
  }
}

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command2 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("Second command");
      MyContext myContext = (MyContext)context;
      myContext.setEmail("admin@twit88.com");
      return false;
  }
}

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command3 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("Third command");
      MyContext myContext = (MyContext)context;
      System.out.println("name: " + myContext.getName());
      System.out.println("email: " + myContext.getEmail());
      return false;
  }
}

I defined the sequence of processing in a configuration file.

<catalog>

<!-- Single command "chains"
       from CatalogBaseTestCase -->
<command   name="MyFirstCommand"
      className="Command1"/>
<command   name="MySecondCommand"
      className="Command2"/>
<command   name="MySecondCommand"
      className="Command3"/>

<!-- Chains with nested commands -->

<chain     name="MyFlow">
  <command   id="1"
      className="Command1"/>
  <command   id="2"
      className="Command2"/>
  <command   id="3"
      className="Command3"/>
</chain>

</catalog>

Then I can test it.

import org.apache.commons.chain.Catalog;
import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;
import org.apache.commons.chain.config.ConfigParser;
import org.apache.commons.chain.impl.CatalogFactoryBase;

public class TestChain {

  private static final String CONFIG_FILE = "/chain.xml";
  private ConfigParser parser;
  private Catalog catalog;

  public TestChain() {
      parser = new ConfigParser();
  }

  public Catalog getCatalog() throws Exception {
      if (catalog == null) {
          parser.parse(
            this.getClass().getResource(CONFIG_FILE));

      }
      catalog = CatalogFactoryBase.getInstance().getCatalog();
      return catalog;
  }

  public static void main(String[] args) throws Exception {
      TestChain chain = new TestChain();
      Catalog catalog = chain.getCatalog();
      Command command = catalog.getCommand("MyFlow");
      Context ctx = new MyContext();
      command.execute(ctx);
  }

}

The output

First command
Second command
Third command
name: twit88
email: admin@twit88.com

Courtsey:
http://twit88.com/blog/2008/03/17/design-pattern-design-a-simple-workflow-using-chain-of-responsibility-pattern/