🚗 Mastering the Strategy Pattern in C#:

Stop using inheritance for behavior.

If there is one lesson that elevates a developer from “Junior” to “Senior,” it’s learning to prefer Composition over Inheritance. The Strategy Pattern is the ultimate manifestation of this principle.

In this deep dive, we are going to look at a common scenario—building a car manufacturing system. We will see how a naive approach traps us in a web of dependencies (The “God Class”), and how the Strategy Pattern acts as a “Plugin System” to restore sanity, testability, and flexibility.

1. The Domain Scenario

Imagine we are building the software backbone for a futuristic automotive group. We have three manufacturers:

• Company A: Makes standard economy cars.

• Company B: Makes hybrids.

• Company C: An experimental division working on flying cars and AI.

The Challenge: We need to model these cars. Some fly, some don’t. Some use petrol, some use electric, some are hybrid. New features (like “Autonomous Mode”) are coming next year.

2. The Naive Approach (The Trap)

The instinctual approach is to use inheritance. We create a base Car class and shove every possible feature into it.

public abstract class Car
{

    // Core features

    public void Drive() { /* ... */ }

    // The Problem: Anticipating every future feature in the base class

    public virtual void Fly() { /* Default implementation? Empty? Throw Exception? */ }

    public virtual void ActivateHybrid() { /* ... */ }

    public virtual void AutonomousPark() { /* ... */ }

}

Why this fails (The “God Class” Anti-Pattern)

As soon as you create EconomyCar (which can’t fly) or VintageCar (which isn’t hybrid), you hit a wall.

1. Polluted Interface: EconomyCar technically has a .Fly() method. This is confusing for other developers using your code.

2. Liskov Substitution Violation: You might override Fly() to throw a NotImplementedException. Now, any code iterating through a list of Car objects and calling .Fly() risks crashing the application.

3. Fragile Base Class: If Company C needs a change to the Fly logic, you might edit the base class, accidentally breaking Company A‘s code.

3. The Solution: The Strategy Pattern

The Strategy Pattern suggests: Take what varies and encapsulate it.

Instead of the Car being the behavior, the Car has a behavior. We break the monolithic Car class into a host and a set of pluggable components.

Step 1: Define the Interfaces (The Sockets)

We identify the behaviors that vary: Flying and Powertrain.

// The contract for any flying behavior

public interface IFlyStrategy

{

    void Fly();

}

// The contract for any engine behavior

public interface IPowertrainStrategy

{

    void Drive();

}

Step 2: Implement the Strategies (The Plugs)

We create concrete classes for every variation. These are small, easy to test, and isolated.

// --- Flying Strategies ---

public class JetPropulsion : IFlyStrategy

{

    public void Fly() => Console.WriteLine(”🚀 Thrusters engaged! We are flying.”);

}

public class NoFly : IFlyStrategy

{

    public void Fly() => Console.WriteLine(”🚫 This car cannot fly.”);

}

// --- Powertrain Strategies ---

public class PetrolEngine : IPowertrainStrategy

{

    public void Drive() => Console.WriteLine(”⛽ Vroom! Driving on petrol.”);

}

public class ElectricEngine : IPowertrainStrategy

{

    public void Drive() => Console.WriteLine(”⚡ Silent but deadly. Driving on electric.”);

}

Step 3: The Context (The Car)

The Car class no longer implements the logic. It simply holds references to the interfaces and delegates the work.

public abstract class Car

{

    // Composition: The Car HAS strategies

    private IFlyStrategy _flyStrategy;

    private IPowertrainStrategy _powertrainStrategy;

    // We can inject strategies via constructor

    protected Car(IFlyStrategy flyStrategy, IPowertrainStrategy powertrainStrategy)

    {

        _flyStrategy = flyStrategy;

        _powertrainStrategy = powertrainStrategy;

    }

    // Dynamic Swapping: We can change behavior at runtime!

    public void SetFlyStrategy(IFlyStrategy newStrategy) => _flyStrategy = newStrategy;

    // Delegation: “I don’t know how to fly, I ask my strategy to do it.”

    public void PerformFly() => _flyStrategy.Fly();

    public void PerformDrive() => _powertrainStrategy.Drive();

}

4. Putting It Together

Now, creating specific car models is just a matter of “configuring” them with the right LEGO blocks.

// Company A: Standard Petrol Car

public class CityCommuter : Car

{

    public CityCommuter() : base(new NoFly(), new PetrolEngine()) { }

}

// Company C: Experimental Flying Car

public class SkyRacer : Car

{

    public SkyRacer() : base(new JetPropulsion(), new ElectricEngine()) { }

}

The “Aha!” Moment: Runtime Swapping

Because we rely on interfaces, we can change a car’s behavior while the program is running. Imagine a video game where a car picks up a “Flight Power-up”:

var myCar = new CityCommuter();

myCar.PerformFly(); // Output: “This car cannot fly.”

// PLAYER PICKS UP POWER-UP

Console.WriteLine(”--- UPGRADE APPLIED ---”);

myCar.SetFlyStrategy(new JetPropulsion());

myCar.PerformFly(); // Output: “Thrusters engaged! We are flying.”

5. Why This is “Clean Code” (SOLID Analysis)

The Strategy Pattern is not just about organizing code; it is about organizing change.

• Naive Code: Resists change. New features break old features.

• Strategy Code: Welcomes change. New features are just new classes waiting to be plugged in.

By decoupling the What (The Car) from the How (The Engine/Wings), you build a system that can evolve as fast as your business requirements.

refer the GITHUB repo for this pattern - the above implementation may differ https://github.com/DileepSreepathi/StrategyDesignPattern