Agile & Lean Software Development Management

The Chain of Responsibility is intended to promote loose coupling between the sender of a request and its receiver by giving more than one object an opportunity to handle the request. The receiving objects are chained and pass the request along the chain until one of the objects handles it.

What I like about this pattern is the chaining part. If the first handler cannot handle the request, the second one will. Or the third, fourth, or … And you only have to call the first handler of the chain.

You must be aware that if you want to use this pattern you should be very keen on exception handling, because the major drawback of this pattern is the possibility that the chain breaks.

And you probably heard this before:

A chain is only as strong as its weakest link

This also holds true for the chain of responsibility pattern. If one handler doesn’t do its work right the working of the following handlers are possibly compromised, which is especially important if the handler is one of the first components in the chain.

The client creates the chain by linking the handlers and does its request to the first handler in the chain, that’s it.

class Client
{
    static void Main()
    {
        Handler handler1 = new ConcreteHandler1();
        Handler handler2 = new ConcreteHandler2();

        handler1.SetSuccessor(handler2);

        handler1.HandleRequest(1);
        handler1.HandleRequest(2);

        Console.ReadKey();
    }
}

As is the case in most design patterns, there is an abstract class. The abstract class Handler defines SetSuccessor, which is responsible for the actual chaining.

abstract class Handler
{
    protected Handler m_Successor;

    public void SetSuccessor(Handler successor)
    {
        this.m_Successor = successor;
    }

    public abstract void HandleRequest(int request);
}

The concrete class implements the actual handling of the request.

// first concrete Handler
class ConcreteHandler1 : Handler
{
    public override void HandleRequest(int request)
    {
        Console.Write("Request {0} is handled by Handler1", request);

        if (request == 1)
        {
            Console.WriteLine();
        }
        else if (m_Successor != null)
        {
            Console.Write("->");
            m_Successor.HandleRequest(request);
        }
    }
}

// second concrete Handler
class ConcreteHandler2 : Handler
{
    public override void HandleRequest(int request)
    {
        Console.Write("Handler2");

        if (request == 2)
        {
            Console.WriteLine();
        }
        else if (m_Successor != null)
        {
            Console.Write("->");
            m_Successor.HandleRequest(request);
        }
    }
}

I also have included a real world example, a message handler which can handle different versions of requests. The first link in the chain handles version 1, the second version 2, and so forth…

Click here for a simplified real world example

class Client
{
    static void Main()
    {
        MessageHandler handler1 = new MessageHandler_v1();
        MessageHandler handler2 = new MessageHandler_v2();
        handler1.SetSuccessor(handler2);
        handler1.HandleRequest("..");
        handler1.HandleRequest("..");
        Console.ReadKey();

    }
}
abstract class MessageHandler
{
    protected MessageHandler m_Successor;
    public void SetSuccessor(MessageHandler successor)
    {
        this.m_Successor = successor;

    }public abstract void HandleRequest(Request request);

}
class MessageHandler_v1 : MessageHandler
{
    public override void HandleRequest(Request request)
    {
        if (request.version == 1)
        {
            // Handle message
        }
        else if (m_Successor != null)
        {
            m_Successor.HandleRequest(request);

        }
    }
}
class MessageHandler_v2 : MessageHandler
{
    public override void HandleRequest(Request request)
    {
        if (request.version == 1)
        {
            // Handle message
        }
        else if (m_Successor != null)
        {
            m_Successor.HandleRequest(request);

        }
    }
}

This post is part of my series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern and look at simplified real-world C# code that implements the pattern.

The Template Design Pattern is used to set up the outline or skeleton of an algorithm, leaving the details to specific implementations later. This way, subclasses can override parts of the algorithm without changing its overall structure.

The template pattern is a relatively simple pattern. You can use it when you have some similar classes with only minor differences and it is possible to isolated the differences into one method while the shared similarities are provided by the base class. Using the template pattern the client only has to instantiate the concrete class and call the desired template method.

class Client
{
    static void Main()
    {
        AbstractClass template = new ConcreteClass();
        template.TemplateMethod();
        Console.ReadKey();
    }
}

The abstract class contains a template method which calls an abstract operation which is defined in the base class and implemented in the concrete class.

abstract class AbstractClass
{
    public void TemplateMethod()
    {
        Operation1();
    }

    protected abstract void Operation1();
}

The concrete class overrides the abstract method of the base class.

class ConcreteClass : AbstractClass
{
    override protected void Operation1()
    {
        Console.WriteLine("Operation1 within ConcreteClass");
    }
}

Thus, the client calls a template method of the base class which calls a method of a concrete class.

Click here for a simplified real world example

class Client
{
    static void Main()
    {
        MessagePacker template = new XmlMessagePacker();
        string message = template.CreateMessage("User324", "Hello, user.");
        Console.WriteLine(message);
        Console.ReadKey();
    }
}

abstract class MessagePacker
{
    public string CreateMessage(string to, string message)
    {
        return Pack(to, message);
    }
    protected abstract string Pack(string to, string message);
}

class XmlMessagePacker : MessagePacker
{
    override protected string Pack(string to, string message)
    {
        return string.Format("{0}{1}", to, message);
    }
}

This post is part of a series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.

The Interpreter pattern is intended to provide you with a way to define representation of the grammar of a language whith an interpreter that uses the representation to interpret sentences in the language.

Some applications provide support for built-in scripting and macro languages so users can describe operations they can perform in the application. If this ability is what you want, then I am sorry to inform you: please use one of the many scripting engines available, for example CS-Script – The C# Script Engine.

The interpreter pattern is especially useful for parsing algorithmic expressions, but it is also very useful for interpretation of small strings containing foreign code. On the net you can find an abundance of examples that use the interpreter pattern for conversion of a Roman numeral to a decimal.

Nice as it is, but instead of ruminating the Roman example we will apply the interpreter pattern for conversion of binary code to decimal.

All you have to do in the client is to construct an interpretation tree, and later on to walk the tree with the provided context. The context contains all necessary information that is global to the interpreter.

class Client
{
    static void Main()
    {
        string input = "00100011";
        Context context = new Context(input);

        // Construct interpretation tree
        ArrayList list = new ArrayList();
        for (int i = 0; i < input.Length; i++) list.Add(new TerminalExpression());

        // Interpret
        foreach (AbstractExpression expression in list)
        {
            expression.Interpret(context);
        }

        Console.WriteLine("interpret {0} = {1}", input, context.Output);
        Console.ReadKey();
    }
}

In our case, the context contains a binary input and a decimal output. I know, these should be properties instead of global variables. So you should refactor them.

class Context
{
    public string Input;
    public int Output;
    public Context(string input)
    {
        this.Input = input;
    }
}

The base class AbstractExpression is the mother of all expressions. Maybe you should refactor it to an interface. In this example it contains one abstract method which receives the context.

abstract class AbstractExpression
{
    public abstract void Interpret(Context context);

}

As always the concrete class does all the work, conversion of binary code to decimal. It’s no rocket science, but nicely shows how this pattern works.

class TerminalExpression : AbstractExpression
{
    public override void Interpret(Context context)
    {
        int power = context.Input.Length - 1;
        if (context.Input.StartsWith("1"))
        {
            context.Output += (int)Math.Pow(2, power );

            } context.Input = context.Input.Remove(0, 1);

        }
    }

At this point you probably are thinking: Hey, where is the NonTerminalExpression? Honestly, I tried to use it in the example, but the example became a little bit to complex. So I purged it. On the other hand, you probably would not use it very often in real world situations, except for building a calculator.

The expression "5*(3+2)" contains the nonterminal expression "(3+2)". You could rewrite the expression like this:

a=3+2;
5*a; 

If you want to try this yourself and incorporate a nonterminal expression, be my guest. I will wait right here for you. See you later, then.

This post is part of my series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern and look at simplified real-world C# code that implements the pattern.