Design Pattern : Memento Pattern

Memento Design Pattern allows to capture internal state of an object in an external object and restore it to the desired checkpoint when required, all the while being in compliance with encapsulation.

The Memento Design Pattern comprises of 3 actor classes.

  • Originator : The class which needs to have the ability to store its internal state and restore itself to checkpoint when required.
  • Memento : Contains the internal state of Originator.
  • Caretaker : The shepherd class who is in charge of storing and restoring Originator from Memento.

Let’s go ahead and implement the actor classes

Classic Approach

public class Memento
    {
        public string FName { get; set; }
        public string LName { get; set; }

    }

 public class Caretaker<TSource>
    {

        private IList<Memento> _stateMemory;

        public Caretaker()
        {
            _stateMemory = new List<Memento>();
        }

        public Memento GoBack(int level) =>  _stateMemory.Reverse().Skip(level-1).First();

}

 public class Originator: IOriginator
    {
        public string FName { get; set; }
        public string LName { get; set; }

        public void RestoreState(Memento memento)
        {
            this.FName = memento.FName;
            this.LName = memento.LName;
        }

        public Memento Save()
        {
            return new Memento() {
                LName = this.LName,
                FName = this.FName
            };
        }

    }

The above code showcases the implementation of Memento in its simplest form. You could step up things by making the Memento generic so that it can be reused with other classes as well.

Generic Memento with Serialization.

Instead of defining each properties of the Originator class, we could create a completely generic version by utilizing the powers of serialization.

In the following example implementation of Memento class, I have used ProtoBuf for serializing the class.

public class Memento<TSource>
    {
        private byte[] _state;

        public Memento(TSource data)
        {
            using(var stream = new MemoryStream())
            {
                ProtoBuf.Serializer.Serialize<TSource>(stream, data);
                _state = stream.ToArray();
            }
        }

        public TSource Value
        {
            get
            {
                using(var stream = new MemoryStream(_state))
                {
                    return ProtoBuf.Serializer.Deserialize<TSource>(stream);
                }
            }
        }
    }

The entire source code shown in this example are available in my GitHub.

Advertisements

Design Patterns : Bridge Pattern

The essence of Bridge Pattern lies in the fact that it not just decouples the abstraction from implementation, but in doing so, allows both to evolve independently. Let’s consider the examples of smartphones.

The underlying OS (for sake of example, let’s assume its Android) improving every year. The Android has seen atleast 7 versions in past decade. At the same time, the hardware has also evolved, giving way to new age smartphones. The Abstraction and Implementation has evolved independently here. Let’s mock the scenario using Bridge Pattern.

public interface IAndroid
{
  void Call(string name);
  void Recieve();
  void SendMessage(string name);
  void RecieveMessage();
}
public class KitKat : IAndroid
{
  public void Call(string name) => Console.WriteLine($"Calling {name} using  KitKat");
  public void Recieve() => Console.WriteLine("Recieve using KitKat");
  public void RecieveMessage()=> Console.WriteLine("Recieve Message using  KitKat");
  public void SendMessage(string name) => Console.WriteLine($"Send {name}  Message using KitKat");
}
public class Lollipop : IAndroid
{
  public void Call(string name) => Console.WriteLine($"Calling {name} using  Lollipop");
  public void Recieve() => Console.WriteLine("Recieve using Lollipop");
  public void RecieveMessage() => Console.WriteLine("Recieve Message using  Lollipop");
  public void SendMessage(string name) => Console.WriteLine($"Send {name}  Message using Lollipop");
}
public class Nougat : IAndroid
{
  public void Call(string name) => Console.WriteLine($"Calling {name} using  Nougat");
  public void Recieve() => Console.WriteLine("Recieve using Nougat");
  public void RecieveMessage() => Console.WriteLine("Recieve Message using  Nougat");
  public void SendMessage(string name) => Console.WriteLine($"Send {name}  Message using Nougat");
}

Evolution of Abstraction which Customer/Client sees, the Phone , can be seen in following code.

public class SmartPhone
{
  protected IAndroid _android;
  public SmartPhone(IAndroid android) => _android = android;
  public virtual void Phone(string name) => _android.Call(name);
  public virtual void SendMessage(string name) =>  _android.SendMessage(name);
}
public class NewAgeSmartPhone : SmartPhone
{
  public NewAgeSmartPhone(IAndroid android) : base(android) { }
  public override void Phone(string name)
  {
    Console.WriteLine("New Age Phone Call, Optimization started");
    base._android.Call(name);
  }
  public override void SendMessage(string name)
  {
    Console.WriteLine("New Age Message");
    _android.SendMessage(name);
  }
}

 

Client Code can be shown as following

static void Main(string[] args)
{
  var phone = new SmartPhone(new KitKat());
  var newAgePhone = new NewAgeSmartPhone(new KitKat());
  phone.Phone("Wife");
  newAgePhone.Phone("Wife");
}

 

As seen in the code above, the Bridge Pattern allows the Abstraction and Implementation to vary and evolve independently. Complete Code Sample in this example can found in my GitHub

Design Patterns : Prototype Pattern

Falling under Creational Patterns, Prototype Pattern aims in creating a clone of your object and is used in scenarios when creating a object is considered costly (may be the creation involves a long Database or Web Service Operation). The formal definition of the pattern is as follows.

 

Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
It is one of the most easiest patterns to implement using .Net Framework.  Let’s define our target class first.
public interface IPerson
{
  string FirstName { get; set; }
  string LastName { get; set; }
  int Age { get; set; }
}
public class Person : IPerson
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public int Age { get; set; }
}

What we need next is an interface that defines our Clone method. One option we have is to define a custom interface which exposes our required method, such as following.

public interface ShallowClone
{
   IPerson Clone(IPerson person);
}

The alternative is to use framework interface ICloneable. For this example, we would be using the framework interface. So let’s go ahead and update the Person Class with implementation of ICloneable.

public class Person : IPerson, ICloneable
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public int Age { get; set; }
  public object Clone() => MemberwiseClone();
}

That’s all we need to do. The MemberwiseClone() method does the trick for us. We will complete the example by writing the Client code.

static void Main(string[] args)
{
  Person personA = new Person { FirstName = "John", LastName= "Burton",  Age = 35 };
  Person personB = personA.Clone() as Person;
  Console.WriteLine($"Person A : {personA.LastName},{personA.FirstName}  - Age : {personA.Age}");
  Console.WriteLine($"Person B : {personB.LastName},{personB.FirstName}  - Age : {personB.Age}");

}

All code samples in this example is available in my GitHub.

Design Patterns : Decorator Pattern

While Inheritance/Sub Classing seems to be most natural way of extending functionality, it might not be always the best option. Especially when you want to avoid subclassing as it might result in too many classes. Consider the following scenario.

Your nearest Dominos has many varieties of Pizzas. On top of it, you could decorate each of those pizzas with extra toppings and choose from a variety of crusts. If we were go with the conventional sub classing approach, we could end up with a lot of sub classes as seen below.
Pizza

For each combination of Pizza and topping, we would need to create a separate sub class. Add to it, options available for crust, and the sub classes could go up higher. This is here Decorator Pattern comes into picture. Decorator Pattern allows us to add functionality/feature to existing classes without having to go through the pain of too many sub classes. Of course, Decorator Pattern too does make use of inheritance, but in a more efficient way.

 

Let’s go ahead and Implement Pizza Classes using Decorator Pattern, beginning with the Contract Interface and choice of base Pizzas.
public interface IPizza
{
  string Description { get; }
  int CalculatePrice();
}

public class MexicanGreenWavePizza : IPizza
{
  public string Description => "Mexican Green Wave Pizza";
  public int CalculatePrice() => 105;
}

public class MargheritaPizza : IPizza
{
  public string Description => "Margherita Pizza";
  public int CalculatePrice() => 100;
}

public class ChickenTikkaPizza : IPizza
{
  public string Description => "Chicken Tikka Pizza";
  public int CalculatePrice() => 115;
}

We will now add our decorators.

class CheeseCrust : IPizza
{
  private IPizza _PizzaInstance;
  public CheeseCrust(IPizza pizza) => _PizzaInstance = pizza;
  public string Description => $"{_PizzaInstance.Description} With Cheese  Crust";
  public int CalculatePrice() => _PizzaInstance.CalculatePrice() + 7;
}

public class ExtraGoldenCorn : IPizza
{
  private IPizza _PizzaInstance;
  public ExtraGoldenCorn(IPizza pizza) => _PizzaInstance = pizza;

  public string Description => $"{_PizzaInstance.Description} with Extra  Golden Corn";
  public int CalculatePrice() => _PizzaInstance.CalculatePrice() + 5;
}

As you might have already noticed, the decorator classes not just inherit from IPizza interface, but it also have an instance of Pizza with it, injected using Dependency Injection.  This allows us to use the decorators with any combination of base classes (and with each other) without having to write too many sub classes as we had observed in the image above. The client can now use any combination of Pizza’s with their decorators.

IPizza vegPizza = new MargheritaPizza();
var vegPizzacheezeCrust = new CheeseCrust(vegPizza); // Added  Decorator

IPizza nonVegPizza = new ChickenTikkaPizza();
var chickenPizzacheezeCrust = new CheeseCrust(nonVegPizza); // Added  Decorator
var chickenPizzacheezeCrustAndExtraGoldenCoren = new  ExtraGoldenCorn(chickenPizzacheezeCrust); // Added Decorator

Console.WriteLine($"{vegPizzacheezeCrust.Description}, Price  :  {vegPizzacheezeCrust.CalculatePrice()}");
Console.WriteLine($"{chickenPizzacheezeCrustAndExtraGoldenCoren.Description},  Price  : {chickenPizzacheezeCrustAndExtraGoldenCoren.CalculatePrice()}");

Output

Margherita Pizza With Cheese Crust, Price  : 107
Chicken Tikka Pizza With Cheese Crust with Extra Golden Corn, Price  : 127<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>

The complete reference source code for the example can be found in my Github. To learn more on Design Patterns, refer here.

Design Patterns : State Pattern

State Pattern is share a lot of similarities with Strategy Pattern, but has its own fundamental differences as well. The State pattern allows to change the behavior of a method, depending on the state of an object, in other words it encapsulates the behavior dependent on the state (the What). This is different from the Strategy Pattern which encapsulates the algorithm (the How).

As always, let’s begin by writing a code that showcases the issues faced when we are not using State Pattern.
public enum eState
{
  CardNotInserted,
  NotValidated,
  Validated
}
public class ATMWithoutState
{
  public eState CurrentState { get; set; }


  public void DoOperation()
  {
    switch (CurrentState)
    {
     case eState.CardNotInserted:
        Console.WriteLine("Current: Card Not Inserted, Next: Insert Your Card");
        break;
     case eState.NotValidated:
        Console.WriteLine("Current: Not Valided, Next: Validate your card by entering PIN");
        break;
case eState.Validated:
       Console.WriteLine("Current: Validated, Next: Please enter amount to withdraw");
       break;
    }
  }
}

The switch case exposes the most obvious flaw of this approach, we need to alter the class to add a new state, which is a clear violation of the Open Closed Principle. This is where the State Pattern comes into play, which gives a separate behavior for DoOperation method for different states of Object.

public interface IAtmState
{
  void DoOperation();
}

public class ATMWithState
{
  public IAtmState CurrentState { get; set; }

  public void DoOperation()
  {
    CurrentState.DoOperation();
  }
}

public class CardNotInsertedState : IAtmState
{
  public void DoOperation()
  {
    Console.WriteLine("Current: Card Not Inserted, Next: Insert Your Card");
  }
}

public class NotValidatedState : IAtmState
{
  public void DoOperation()
  {
    Console.WriteLine("Current: Not Valided, Next: Validate your card by entering PIN");
  }
}

public class ValidatedState : IAtmState
{
  public void DoOperation()
  {
    Console.WriteLine("Current: Validated, Next: Please enter amount to withdraw");
  }
}

The complete code described in this post in available in my GitHub.

Design Patterns : Null Object Pattern

Null Pattern is probably one of the most underestimated and often most ignored among the design Patterns., though it turns out to be one of the easiest to implement. The intend of the pattern is to ensure we won’t end up with NullReference Exceptions, while avoiding the long list of repeated preconditions that checks of null values. Instead, we provide identify and define the behavior when null object is encountered , encapsulate it in a object, and use it as you would normally use any other valid instance of the object.

Consider the following code.

public class Person :IPerson
{
public long ID {get;set;}
public List GetEmployementHistory()
{
   // Do some operations from Db
}
}

// Client Code 

void Main()
{
   var Employee = EmployeeCollection.GetEmployee();
   var details = Employee.GetEmployementHistory();
}

The above code would throw an exception if the Employee Parameter is null. The obvious solution would be to use preconditions to ensure we handle null values in appropriate manner. We would have to rewrite the code as follows.

void Main()
{
   var Employee = EmployeeCollection.GetEmployee();
   if(Employee == null)
   {
      // Do appropriate action
   }
   var details = Employee.GetEmployementHistory ();
}

However, this approach would mean that the client that invoke the GetDetails method needs to be ensure the object isn’t null. This is an unnecessary burden on the client, and on a longer run, and the chances of a client forgetting to validate the object is higher.

Null Object Pattern

As mentioned earlier, the Null Object Pattern aims to provide a default behavior ( or no behavior at all) when a null instance is encountered by encapsulating the behavior within an instance. We would do so by providing special implementation of the type, which encapsulate the behavior associated with null object.

For example, for the above code, the null object pattern could be defined as

public class NullPerson: IPerson
{
  public long ID {get;set;} = -1;
  public List GetEmployementHistory()
  {
    return new List();
  }
}

Now we could rewrite the Client Code sans any preconditions without worrying about the null exceptions. However, here is a word of caution. We shouldn’t use the Null Object Pattern to swallow the exception unless that’s a behavior we really want. Another scenario one needs to avoid while using the Null Object Pattern is the usage of “IsNull” Properties/Method. At times , we do come across Null Object Implementation that includes a property/method which states where the object is null. For example, consider the following code.

public class NullPerson: IPerson
{
  public bool IsNull {get;set;} => false;
  public long ID {get;set;} = -1;
  public List GetEmployementHistory()
  {
    return new List();
  }
}

This is NOT Null Object Pattern as it defeats the purpose of the pattern.It causes the logic to be spilled outside the object.

Sample code for Null Object Pattern can be found in my GitHub

Design Patterns : Adapter Pattern

There is already a large amount of literature on the Internet which discusses Adapter Pattern. However, the purpose of article is to showcase the implementations of the Adapter Pattern, rather than discussing the application of the pattern. In this post, adapter class is implemented using

1. Inheritance
2. Dependency Injection
3. Generics

Consider your old legacy code, which has a single method, GetEmployeeList.

public interface IHRSoftware
    {
        List<string> GetEmployeeNameList();
    }
    public class HRSoftware : IHRSoftware
    {
        public List<string> GetEmployeeNameList()
        {
            return new List<string>() { "Jia", "Anu", "Sreena" };
        }
    }

Client, consumes the class as follows.

            IHRSoftware hrsoft = new HRSoftware();
            foreach (var item in hrsoft.GetEmployeeNameList())
            {
                Console.WriteLine(item);
            }

Now, it so happened that the Client has gone through an overhaul and is now looking to use a new contract (interface), namely INewAgeSoftware, which exposes a property EmployeeList, replacing the GetEmployeeNameList Method. The interface declaration is as shown below.

    public interface INewAgeHRSoftware
    {
        List<string> EmployeeList { get;  }
    }

You however, would like to use your old existing code, without actually going ahead and making the changes in your legacy code. This is where adapter pattern come in handy. Following are different implementations of Adapter Class

1. Using Inheritance.

    public class AdapterWithInheritence : HRSoftware, INewAgeHRSoftware
    {

        public List<string> EmployeeList
        {
            get
            {
                return this.GetEmployeeNameList();
            }
        }
    }

2. Using Dependency Injection

    public class AdapterWithDI : INewAgeHRSoftware
    {
        private IHRSoftware _HRInstance;
        public AdapterWithDI(IHRSoftware HRSoftInstance)
        {
            _HRInstance = HRSoftInstance;
        }
        public List<string> EmployeeList
        {
            get
            {
                return _HRInstance.GetEmployeeNameList();
            }
        }
    }

3. And Finally, using Generics

    public class AdapterWithGenerics<T> : INewAgeHRSoftware where T : HRSoftware
    {
        private T _HRInstance;
        public AdapterWithGenerics(T Instance)
        {
            _HRInstance = Instance;
        }

        public List<string> EmployeeList
        {
            get
            {
                return _HRInstance.GetEmployeeNameList();
            }
        }
    }

Your new Client class would now look as follows

 Console.WriteLine("Fetching from NewAgeHRSoftware - Adapter via Inheritence");
            INewAgeHRSoftware newhrsoftInheritence = new AdapterWithInheritence();
            foreach (var item in newhrsoftInheritence.EmployeeList)
            {
                Console.WriteLine(item);
            }
            Console.WriteLine("Fetching from NewAgeHRSoftware - Adapter via DI");
            INewAgeHRSoftware newhrsoftDI = new AdapterWithDI(new HRSoftware());
            foreach (var item in newhrsoftInheritence.EmployeeList)
            {
                Console.WriteLine(item);
            }

            Console.WriteLine("Fetching from NewAgeHRSoftware - Adapter via Generics");
            INewAgeHRSoftware newhrsoftGenerics= new AdapterWithGenerics<HRSoftware>(new HRSoftware());
            foreach (var item in newhrsoftGenerics.EmployeeList)
            {
                Console.WriteLine(item);
            }