Design Pattern 3 - Factory Method Pattern

The Factory Method pattern allows for the instantiation of objects at runtime. We can think of Factory Pattern as a factory which is responsible for "manufacturing" an object. A Parameterized Factory receives the name of the class to instantiate as argument.

Obviously, a factory is not needed to make an object. A simple call to new will do it for you. However, the use of factories gives the programmer the opportunity to abstract the specific attributes of an Object into specific subclasses which create them. In addition, one principle in OOP programming is to reduce coupling. Avoid using new key work means we also avoid the dependency between classes which make it much easier for unit testing.



There is one very good article in Wikipedia about Factory Method pattern, where using an example of Pizza factory produce different type of Pizzas. The code is in Java, with a little effort I have re-written it in C# as the code shown below:

using System;

namespace FactoryMethodPattern
{
    abstract class Pizza
    {
        public abstract double getPrice();
    }

    class HamAndMushroomPizza : Pizza
    {
        public override double getPrice()
        {
            return 8.5;
        }
    }

    class DeluxePizza : Pizza
    {
        public override double getPrice()
        {
            return 10.5;
        }
    }

    class HawaiianPizza : Pizza
    {
        public override double getPrice()
        {
            return 11.5;
        }
    }

    class PizzaFactory
    {
        public enum PizzaType
        {
            HamMushroom,
            Deluxe,
            Hawaiian
        }

        public static Pizza createPizza(PizzaType pizzaType)
        {
            switch (pizzaType)
            {
                case PizzaType.HamMushroom:
                    return new HamAndMushroomPizza();
                case PizzaType.Deluxe:
                    return new DeluxePizza();
                case PizzaType.Hawaiian:
                    return new HawaiianPizza();
                default:
                    return null;
            }            
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            // Loop with foreach through a Enum
            foreach (PizzaFactory.PizzaType pizzaType in 
                Enum.GetValues(typeof(PizzaFactory.PizzaType)))             
            {
                Console.WriteLine("Price of " + pizzaType + " is £" 
                    + PizzaFactory.createPizza(pizzaType).getPrice());
            }
        }
    }
}

Reference: Factory method pattern in Wikipedia.

Design Pattern 2 - Decorator Pattern

I finally can’t resist the temptation and joined the Sky Sports a few weeks ago, as I am a big fun of English premiere league. While I was placing the order on the internet, somehow the Decorator pattern came into my mind.

By definition, 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.



To implement Decorator Pattern for sky.com, let us create an interface first, we named it as ITVBundle.

public interface ITVBundle
{
 string Description();
 double Cost();
}

To subscribe sky sports or movie channels, you have to subscribe a basic pack even you don’t want to watch them. So the first class I need to create is BasicPack which implement ITVBundle interface.

public class BasicPack : ITVBundle
{
 public double Cost()
 {
  return 18.50;
 }

 public String Description()
 {
  return "Basic Packs";
 }
}

An decorator abstract class which also implement ITVBundle interface:

public abstract class AddOnDecorator : ITVBundle
{
 public abstract string Description();
 public abstract double Cost();
}

The next bit is my favourite, which is to add Sports packs or Movies Pack to the Basic Pack. This works by adding a new decorator class that wraps the original class. Let’s look at the example below:

public class AddSportsPack : AddOnDecorator
{
 ITVBundle _itv;
 public AddSportsPack(ITVBundle tvBundle)
 {
  this._itv = tvBundle;
 }

 public override string Description()
 {
  return _itv.Description() + ", with Sports Pack";
 }

 public override double Cost()
 {
  return _itv.Cost() + 9.99;
 }
}

From the above you can see the wrapping is typically achieved by passing the original object as a parameter to the constructor of the decorator when it is created. The decorator implements the new functionality, but for functionality that is not new, the original (wrapped) class is used. The decorating class must have the same interface as the original class.

Here is the example on using Decorator Pattern:

BasicPack bp = new BasicPack();
AddSportsPack plan1 = new AddSportsPack(bp);

Please see the full working code:

using System;

namespace DecoratorPattern
{
    public interface ITVBundle
    {
        string Description();
        double Cost();
    }

    public class BasicPack : ITVBundle
    {
        public double Cost()
        {
            return 18.50;
        }

        public String Description()
        {
            return "Basic Packs";
        }
    }

    public abstract class AddOnDecorator : ITVBundle
    {
        public abstract string Description();
        public abstract double Cost();
    }

    public class AddMoviePack : AddOnDecorator
    {
        ITVBundle _itv;
        public AddMoviePack(ITVBundle tvBundle)
        {
            this._itv = tvBundle;
        }

        public override string Description()
        {
            return _itv.Description() + ", with Movie Pack";
        }

        public override double Cost()
        {
            return _itv.Cost() + 9.99;
        }
    }

    public class AddSportsPack : AddOnDecorator
    {
        ITVBundle _itv;
        public AddSportsPack(ITVBundle tvBundle)
        {
            this._itv = tvBundle;
        }

        public override string Description()
        {
            return _itv.Description() + ", with Sports Pack";
        }

        public override double Cost()
        {
            return _itv.Cost() + 9.99;
        }
    }    

    class Program
    {
        static void Main(string[] args)
        {
            BasicPack bp = new BasicPack();
            AddMoviePack plan1 = new AddMoviePack(bp);
            AddSportsPack plan2 = new AddSportsPack(plan1);

            Console.WriteLine("You have choosen plan 2: {0} \nThe cost is: ￡{1}", 
                plan2.Description().ToString(), plan2.Cost().ToString());
        }
    }
}

The output will be looking like:



Use the Decorator pattern when:

- You have an existing component class that may be unavailable for subclassing.
- You want to attach additional state or behaviour to an object dynamically.
- You want to make changes to some objects in a class without affecting others.
- Avoid subclassing because too many classes could result.

Design Pattern 1 – Strategy Pattern

In the past 6 months, I have been reading and studying the well-known book Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (GOF). While studying the book, I do feel it has taken me to the next level of understanding OOP concepts and has given me more confidence to write elegant and reusable code. I think any Object-Oriented software developer should read the book. In my next few articles I will be covering the most frequently used patterns in .net applications.

The first design pattern I’d like to talk about is Strategy Pattern. The main purpose of the Strategy pattern is to decouple concrete code into separate classes, which promotes reusability. As your project grows in size, having reusable modules is a necessity. This pattern also allows you to easily add new modules into a C# ASP .NET software design with limited impact on the rest of the system.



Let’s assume one situation that you are trying to print out a greeting message on screen in different languages. Here is the non-pattern way how your code may look like:

class HelloWorldClientNoPattern
{
 public void SayHello(string strName, string strLanguage)
 {                        
  switch (strLanguage)
  {
   case "english":
    Console.WriteLine("Hello World " + strName);
    break;
   case "spanish":
    Console.WriteLine("Hola mundo " + strName);
    break;
   case "german":
    Console.WriteLine("Hallo Welt " + strName);
    break;                
  }
 }
}

class Program
{
 static void Main(string[] args)
 {
  
  HelloWorldClientNoPattern client = new HelloWorldClientNoPattern();
  client.SayHello("Can Lu", "english");
  client.SayHello("Can Lu", "spanish");
  client.SayHello("Can Lu", "german");

 }                
}

What is wrong with this approach? Well it is nothing wrong it works but there are at least couple of problems.
- The code above is not reusable. If we want to use the SayHello method somewhere else, I have to write the same code again.
- The code is not decoupled. If you want to add a new greeting language. For example if you want to print SayHello in Chinese, you have to modify the client class.

The strategy pattern is to solve this kind of problem. The most important part of the Strategy pattern is the main interface. This is what allows the polymorphism and allows us to pass the client any type of algorithm, as long as it uses the same interface. The interface will look like:

public interface IHelloWorldStrategy
{
 void SayHello(string strName);
}

Then it’s time to create different classes to implement this interface. For example we could have:

class HelloWorldEnglish: IHelloWorldStrategy
{
 public void SayHello(string strName)
 {
  Console.WriteLine("Hello world " + strName);
 }
}

class HelloWorldChinese: IHelloWorldStrategy
{
 public void SayHello(string strName)
 {
  Console.WriteLine("Ni Hao " + strName);
 }
}

Now we can rewrite our client class. Instead of using Switch Case/If then else, we're using an Interface as the implementation of the strategy. This allows us a generic pointer to whichever algorithm we end up actually using.

class HelloWorldClient
{
 IHelloWorldStrategy strategy;
 public HelloWorldClient(IHelloWorldStrategy s)
 {
  this.strategy = s;
 }

 public void SayHello(string strName)
 {
  strategy.SayHello(strName);
 }
}

Notice the constructor takes a variable of the interface type. This is powerful because, if we derive each algorithm class from the same interface, then we can pass the client algorithm and it will be able to handle any kind algorithms that we create; as long as they implement the same interface, can be utilized in this client.

Please find the full working code below:

using System;

namespace StrategyPatternDemo
{
    public interface IHelloWorldStrategy
    {
        void SayHello(string strName);
    }

    class HelloWorldEnglish: IHelloWorldStrategy
    {
        public void SayHello(string strName)
        {
            Console.WriteLine("Hello world " + strName);
        }
    }

    class HelloWorldSpanish : IHelloWorldStrategy
    {
        public void SayHello(string strName)
        {
            Console.WriteLine("Hola mundo " + strName);
        }
    }

    class HelloWorldGerman : IHelloWorldStrategy
    {
        public void SayHello(string strName)
        {
            Console.WriteLine("Hallo Welt " + strName);
        }
    }

    class HelloWorldClient
    {
        IHelloWorldStrategy strategy;
        public HelloWorldClient(IHelloWorldStrategy s)
        {
            this.strategy = s;
        }

        public void SayHello(string strName)
        {
            strategy.SayHello(strName);
        }
    }    

    class Program
    {
        static void Main(string[] args)
        {
            HelloWorldClient myHelloWorld = new HelloWorldClient(new HelloWorldEnglish());
            myHelloWorld.SayHello("Can Lu");

            myHelloWorld = new HelloWorldClient(new HelloWorldSpanish());
            myHelloWorld.SayHello("Can Lu");

            myHelloWorld = new HelloWorldClient(new HelloWorldGerman());
            myHelloWorld.SayHello("Can Lu");            
        }                
    }
}

The output will be like:



There are a number of advantages to structuring a family of algorithms in this manner, but the most important is that doing so decouples the client from the implementation details of any particular algorithm. This promotes extensibility in that additional algorithms can be developed and plugged in seamlessly, as long as they follow the base interface specification, thereby allowing algorithms to vary dynamically. Moreover, the Strategy pattern eliminates conditional statements that would otherwise litter client code. Whenever we have switch case statement in code, we probably need to think twice, should we use Strategy Pattern to replace it.