JSprang JSprang - 26 days ago 16
C# Question

Strategy Pattern with no 'switch' statements?

I've been doing some reading on the Strategy Pattern, and have a question. I have implemented a very basic Console Application below to explain what I'm asking.

I have read that having 'switch' statements is a red flag when implementing the strategy pattern. However, I can't seem to get away from having a switch statement in this example. Am I missing something? I was able to remove the logic from the Pencil, but my Main has a switch statement in it now. I understand that I could easily create a new TriangleDrawer class, and wouldn't have to open the Pencil class, which is good. However, I would need to open Main so that it would know which type of IDrawer to pass to the Pencil. Is this just what needs to be done if I'm relying on the user for input? If there's a way to do this without the switch statement, I'd love to see it!

class Program
{
public class Pencil
{
private IDraw drawer;

public Pencil(IDraw iDrawer)
{
drawer = iDrawer;
}

public void Draw()
{
drawer.Draw();
}
}

public interface IDraw
{
void Draw();
}

public class CircleDrawer : IDraw
{
public void Draw()
{
Console.Write("()\n");
}
}

public class SquareDrawer : IDraw
{
public void Draw()
{
Console.WriteLine("[]\n");
}
}

static void Main(string[] args)
{
Console.WriteLine("What would you like to draw? 1:Circle or 2:Sqaure");

int input;
if (int.TryParse(Console.ReadLine(), out input))
{
Pencil pencil = null;

switch (input)
{
case 1:
pencil = new Pencil(new CircleDrawer());
break;
case 2:
pencil = new Pencil(new SquareDrawer());
break;
default:
return;
}

pencil.Draw();

Console.WriteLine("Press any key to exit...");
Console.ReadKey();
}
}
}


Implemented Solution shown below (Thanks to all who responded!)
This solution got me to the point where the only thing I need to do to use a new IDraw object is to create it.

public class Pencil
{
private IDraw drawer;

public Pencil(IDraw iDrawer)
{
drawer = iDrawer;
}

public void Draw()
{
drawer.Draw();
}
}

public interface IDraw
{
int ID { get; }
void Draw();
}

public class CircleDrawer : IDraw
{

public void Draw()
{
Console.Write("()\n");
}

public int ID
{
get { return 1; }
}
}

public class SquareDrawer : IDraw
{
public void Draw()
{
Console.WriteLine("[]\n");
}

public int ID
{
get { return 2; }
}
}

public static class DrawingBuilderFactor
{
private static List<IDraw> drawers = new List<IDraw>();

public static IDraw GetDrawer(int drawerId)
{
if (drawers.Count == 0)
{
drawers = Assembly.GetExecutingAssembly()
.GetTypes()
.Where(type => typeof(IDraw).IsAssignableFrom(type) && type.IsClass)
.Select(type => Activator.CreateInstance(type))
.Cast<IDraw>()
.ToList();
}

return drawers.Where(drawer => drawer.ID == drawerId).FirstOrDefault();
}
}

static void Main(string[] args)
{
int input = 1;

while (input != 0)
{
Console.WriteLine("What would you like to draw? 1:Circle or 2:Sqaure");

if (int.TryParse(Console.ReadLine(), out input))
{
Pencil pencil = null;

IDraw drawer = DrawingBuilderFactor.GetDrawer(input);

pencil = new Pencil(drawer);
pencil.Draw();
}
}
}

Answer

Strategy isn't a magic anti-switch solution. What it does do is give modularise your code so that instead of a big switch and business logic all mixed up in a maintenance nightmare

  • your business logic is isolated and open for extension
  • you have options as for how you create your concrete classes (see Factory patterns for example)
  • your infrastructure code (your main) can be very clean, free of both

For example - if you took the switch in your main method and created a class which accepted the command line argument and returned an instance of IDraw (i.e. it encapsulates that switch) your main is clean again and your switch is in a class whose sole purpose is to implement that choice.