Introduction:

As a developer, you've probably faced the growing complexity of using too many if else statements in your code. While they work fine for simple conditions, when the number of conditions grows, your code quickly becomes hard to read, maintain, and scale. This is where Design Patterns come into play.

Design patterns are proven, reusable solutions to common design problems that software developers face. They allow you to write more flexible, maintainable, and scalable code by avoiding long chains of if else statements.

In this article, we’ll explore several design patterns that can help you avoid the messy if else logic and organize your code more effectively. Each design pattern will be illustrated with a real-world example to make the concept clear.

The Design Patterns We'll Cover:

  1. Strategy Pattern
  2. Command Pattern
  3. State Pattern
  4. Chain of Responsibility Pattern
  5. Factory Pattern

1. Strategy Pattern: Choose Behavior Dynamically

The Strategy Pattern lets you define a family of algorithms, encapsulate each one, and make them interchangeable. This allows a client to choose the behavior it needs at runtime, without using a series of if else statements.

Real-World Example:

Imagine you're building a payment processing system where a user can choose from different payment methods: credit card, PayPal, or bank transfer. Instead of using if else statements to decide the payment method, you define each payment method as a separate strategy.

public interface IPaymentStrategy
{
    void Pay();
}

public class CreditCardPayment : IPaymentStrategy
{
    public void Pay() { Console.WriteLine("Paying with Credit Card"); }
}

public class PayPalPayment : IPaymentStrategy
{
    public void Pay() { Console.WriteLine("Paying with PayPal"); }
}

public class PaymentProcessor
{
    private readonly IPaymentStrategy _paymentStrategy;

    public PaymentProcessor(IPaymentStrategy paymentStrategy)
    {
        _paymentStrategy = paymentStrategy;
    }

    public void ProcessPayment() { _paymentStrategy.Pay(); }
}

class Program
{
    static void Main(string[] args)
    {
        var processor = new PaymentProcessor(new PayPalPayment());
        processor.ProcessPayment();  // Paying with PayPal
    }
}

Benefits:

  • Flexibility: You can easily add new payment methods without modifying the existing code.
  • Cleaner Code: Each payment method is encapsulated in its own class, making the code more readable.

2. Command Pattern: Encapsulate Requests as Objects

The Command Pattern allows you to encapsulate a request as an object, thereby separating the command from the object that executes it. This helps in reducing complex if else logic when handling various types of requests.

Real-World Example:

In a home automation system, you might have devices like lights, fans, and air conditioners, and you want to perform different actions like turning them on or off. Using the Command Pattern, each device action is encapsulated in its own command.

public interface ICommand
{
    void Execute();
}

public class TurnOnLightCommand : ICommand
{
    public void Execute() { Console.WriteLine("Turning on the light"); }
}

public class TurnOffFanCommand : ICommand
{
    public void Execute() { Console.WriteLine("Turning off the fan"); }
}

public class DeviceControl
{
    private readonly ICommand _command;

    public DeviceControl(ICommand command)
    {
        _command = command;
    }

    public void ExecuteCommand() { _command.Execute(); }
}

class Program
{
    static void Main(string[] args)
    {
        var control = new DeviceControl(new TurnOnLightCommand());
        control.ExecuteCommand();  // Turning on the light
    }
}

Benefits:

  • Separation of Concerns: The logic for the command is separated from the execution.
  • Extensibility: New commands can be added easily without modifying existing code.

3. State Pattern: Alter Behavior Based on State

The State Pattern is used when an object's behavior depends on its state. Instead of using if else to handle state transitions, each state is represented as a class and the object changes its behavior depending on the current state.

Real-World Example:

Imagine you’re designing a shopping cart where the order can be in various states: "Pending", "Shipped", and "Delivered". Each state has a different behavior, such as different methods of processing the order.

public interface IState
{
    void HandleRequest();
}

public class PendingState : IState
{
    public void HandleRequest() { Console.WriteLine("Processing pending order"); }
}

public class ShippedState : IState
{
    public void HandleRequest() { Console.WriteLine("Shipping the order"); }
}

public class DeliveredState : IState
{
    public void HandleRequest() { Console.WriteLine("Delivering the order"); }
}

public class OrderContext
{
    private IState _state;

    public OrderContext(IState state)
    {
        _state = state;
    }

    public void SetState(IState state) { _state = state; }

    public void ProcessRequest() { _state.HandleRequest(); }
}

class Program
{
    static void Main(string[] args)
    {
        var order = new OrderContext(new PendingState());
        order.ProcessRequest();  // Processing pending order

        order.SetState(new ShippedState());
        order.ProcessRequest();  // Shipping the order
    }
}

Benefits:

  • Behavioral Flexibility: The object’s behavior changes depending on its state.
  • Easier Maintenance: Each state is encapsulated in its own class, making it easier to manage and extend.

4. Chain of Responsibility Pattern: Pass Requests Along a Chain

The Chain of Responsibility Pattern allows a request to be passed along a chain of handlers. Each handler decides whether to process the request or pass it along to the next handler. This is particularly useful when handling different types of requests without a large if else block.

Real-World Example:

In a customer service system, you might have different departments handling specific types of requests, such as "Technical Support", "Billing", and "General Inquiry". Each department can handle the request or pass it to the next one in the chain.

public interface IRequestHandler
{
    void SetNextHandler(IRequestHandler handler);
    void HandleRequest(string request);
}

public class TechnicalSupportHandler : IRequestHandler
{
    private IRequestHandler _nextHandler;

    public void SetNextHandler(IRequestHandler handler) { _nextHandler = handler; }

    public void HandleRequest(string request)
    {
        if (request == "Technical Issue")
        {
            Console.WriteLine("Handling technical issue");
        }
        else if (_nextHandler != null)
        {
            _nextHandler.HandleRequest(request);
        }
        else
        {
            Console.WriteLine("Request not handled");
        }
    }
}

public class BillingHandler : IRequestHandler
{
    private IRequestHandler _nextHandler;

    public void SetNextHandler(IRequestHandler handler) { _nextHandler = handler; }

    public void HandleRequest(string request)
    {
        if (request == "Billing Issue")
        {
            Console.WriteLine("Handling billing issue");
        }
        else if (_nextHandler != null)
        {
            _nextHandler.HandleRequest(request);
        }
        else
        {
            Console.WriteLine("Request not handled");
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        IRequestHandler techSupport = new TechnicalSupportHandler();
        IRequestHandler billing = new BillingHandler();

        techSupport.SetNextHandler(billing);

        techSupport.HandleRequest("Technical Issue");  // Handling technical issue
        techSupport.HandleRequest("Billing Issue");  // Handling billing issue
        techSupport.HandleRequest("General Inquiry");  // Request not handled
    }
}

Benefits:

  • Decoupling: The request handling is decoupled from the request sender.
  • Extensibility: New handlers can be added to the chain without modifying the existing code.

5. Factory Pattern: Create Objects Based on Input

The Factory Pattern abstracts the creation of objects and lets you decide what type of object to create based on the input provided. This avoids the need for if else when choosing between different types of objects.

Real-World Example:

Imagine you're designing a car rental system, where customers can choose between different types of cars like "SUV", "Sedan", and "Truck". Instead of using if else to create the car objects, you use a factory to handle object creation.

public interface ICar
{
    void Drive();
}

public class Sedan : ICar
{
    public void Drive() { Console.WriteLine("Driving a Sedan car"); }
}

public class SUV : ICar
{
    public void Drive() { Console.WriteLine("Driving an SUV car"); }
}

public class CarFactory
{
    public ICar GetCar(string carType)
    {
        if (carType == "Sedan") return new Sedan();
        else if (carType == "SUV") return new SUV();
        else throw new ArgumentException("Unknown car type");
    }
}

class Program
{
    static void Main(string[] args)
    {
        var factory = new CarFactory();
        var car = factory.GetCar("SUV");
        car.D

rive();  // Driving an SUV car
    }
}

Benefits:

  • Simplified Object Creation: The factory handles the logic of creating objects, avoiding multiple if else statements.
  • Flexibility: You can easily modify or extend object creation logic without impacting other parts of the code.

Conclusion:

By using the right Design Patterns, you can avoid the messy, hard-to-maintain code created by excessive if else statements. Each pattern offers a different way to simplify decision-making in your code, making it more flexible, readable, and easier to extend in the future.

Whether you're handling different behaviors (Strategy), requests (Command), states (State), chains of responsibility (Chain of Responsibility), or object creation (Factory), these patterns give you clean and scalable solutions for real-world problems.

Author Of article : ahmedmohamedhussein Read full article