Archive

Posts Tagged ‘Behavioral Design Pattern’

Strategy Design Pattern in .Net

September 26, 2010 Leave a comment

Strategy design pattern falls under the category of Behavioral Design Pattern. In this pattern, we capture abstraction in an Interface or Abstract class called Strategy Base, and we bury implementation details of algorithms in concrete classes called Concrete Strategy. Client code can then call such different implementation methods based upon some strategy or condition during run time. Client is not tied statically or bound to call fixed methods, rather it can change its strategy dynamically. This is because client never calls any methods directly by instantiating concrete classes. Client sets its strategy via some other class called Context.

Let’s see one such example of this pattern.

StrategyDesignPattern
Fig: Strategy Design Pattern showing all three main components- Strategy Base, Concrete Strategy and Context Classes.

Coming to code, we have:

namespace BehavioralDesignPattern.StrategyDesignPattern
{
public abstract class StrategyBase
{
public abstract long Calculate(int x,int y);
}

public class ConcreteAddStrategy : StrategyBase
{
public override long Calculate(int x, int y)
{
return x + y;
}
}

public class ConcreteSubtractStrategy : StrategyBase
{
public override long Calculate(int x, int y)
{
return x - y;
}
}

public class Context
{
public StrategyBase Strategy { get; set; }
public long CallCalculateMethod(int x, int y)
{
return (Strategy.Calculate(x, y));
}
}
}

We see each of the concrete strategy class implementing algorithm to calculate upon numbers in its own way- one doing addition, while other doing subtraction. But their over all capability to do arithmetic operations upon numbers is abstracted inside Calculate(int, int) method in StrategyBase class.

See the Context class above. It has a property Strategy to get-set of type StrategyBase type. Alternatively, Context class can get-set instance of StrategyBase by a constructor or some method as well like SetStrategy(StrategyBase objSB).

But why do we require this Context class? Because clients agree to call any ConcreteStrategy method not directly. Clients will only hint out for such concrete strategy. What does this mean? This means a lot- Strategy pattern lets you change the guts of an object.

See the client code below:

private void CallStrategyAddMethod()
{
//
Context objCtxt = new Context();
objCtxt.Strategy = new ConcreteAddStrategy();
// Now the object's strategy is to call Add method.
objCtxt.CallCalculateMethod(10, 15);
}

As seen from the above code, object “objCtxt” is able to call method in a concrete strategy class.

Whenever modeling a system after Strategy Design Pattern, one has to carefully think of a way to allow client to convey its strategy to context class.

That’s it.

Advertisements

Template Method Design Pattern in .Net

September 26, 2010 Leave a comment

Template method design pattern falls under the category of Behavioral Design Pattern. In this pattern, a template method defines a skeleton of an algorithm in terms of abstract operations. The template method can contain one or more steps. But these steps will have to be in abstract form only. That said, we cannot change the order of steps, and most importantly we cannot override the template method itself. Only the steps given in the skeleton of algorithm of template method need to be overridden in concrete classes.

Let’s see how classes can be designed in this template pattern.

emplateMethodPattern

Fig: High Level Class Diagram of Template Method Design Pattern

And see the code implementation below:

namespace BehavioralDesignPattern.TemplateMethod
{
public abstract class AbstractAlgorithmSkeleton
{
public void TemplateMethod()
{
// Template Method declaring algorithm
// in terms of abstract operations.
Step1();
Step2();
Step3();
}
public abstract void Step1();
public abstract void Step2();
public abstract void Step3();
}

# region "Concrete Implementations of abstract operations defined in Template Method"
public class ConcreteClassA : AbstractAlgorithmSkeleton
{
public override void Step1()
{
Console.WriteLine("ConcreteClassA, Step 1");
}

public override void Step2()
{
Console.WriteLine("ConcreteClassA, Step 2");
}

public override void Step3()
{
Console.WriteLine("ConcreteClassA, Step 3");
}

public void OtherMethodA()
{
//
}
}

public class ConcreteClassB : AbstractAlgorithmSkeleton
{
public override void Step1()
{
Console.WriteLine("ConcreteClassB, Step 1");
}

public override void Step2()
{
Console.WriteLine("ConcreteClassB, Step 2");
}

public override void Step3()
{
Console.WriteLine("ConcreteClassB, Step 3");
}

public void OtherMethodB()
{
//
}
}

# endregion "Concrete Classes Implementation"
}

We see the concrete classes are overriding the abstract operations defined by the template method in its algorithm. This way template method pattern provides an abstract view of algorithm.

So in practical scenario, this pattern fits only when different types of object instances are required to invoke methods or operations that differ sharply in implementation but the algorithm remaining same. Also, sometimes when are refactoring multiple classes, we can find template method pattern coming into picture.

Consuming the template method:

private void CallTemplateMethod()
{
AbstractAlgorithmSkeleton objTemplate = null;
objTemplate = new ConcreteClassA();
// Now this call to TemplateMethod() will direct calls
// to methods in ConcreteClassA.
objTemplate.TemplateMethod();
}

Important point to note here is: the way we are calling TemplateMethod() of ConcreteClassA from base class AbstractAlgorithmSkeleton reminds us of “The Hollywood Principle”- “Do not call us, we will call for you”. That is, child class method is being called from base class. This way of method call is also known as Inversion of Control.

That’s it.