Design Patterns : 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.