Archive for the ‘S.O.L.I.D’ Category

Refactoring Switch Statements With StructureMap

Friday, October 23rd, 2009

Switch statements are commonly regarded as code smells, especially when the number of switch statements becomes very large. For this example I’m going to show you the traditional approach to refactor out a switch statement in C# and how you can further refine this approach using StructureMap though this would be possible using any IOC container.

Consider the following switch statement which I’ve kept fairly simple for the purpose of  demonstration:

public void ProcessCommand(Command command)
        {
            switch (command)
            {
                case Command.Go:
                    Console.WriteLine("Go");
                    break;

                case Command.Pause:
                    Console.WriteLine("Pause");
                    break;

                case Command.Stop:
                    Console.WriteLine("Stop");
                    break;

                default:
                    throw new Exception("Unhandled Command");
            }
        }

The Classic Approach To Refactoring Switch Statements

Normally when refactoring a switch statement we would perform the following steps:

1) Create an abstract/interface for a handler e.g.

public interface ICommandHandler
{
    void Handle();
}

2) For each case statement create a concrete implementation of our abstract handler  e.g.

 public class GoHandler:ICommandHandler
    {
        public void Handle()
        {
            Console.WriteLine("Go");
        }

        public bool Handles(Command type)
        {
            return Command.Go == type;
        }
    }

3) Create a Dictionary of our handlers using our switch statement key for our dictionary key e.g.

    public class RefactoredWithDictionary
    {
        private readonly Dictionary _commandHandlers;

        public RefactoredWithDictionary()
        {
            _commandHandlers = new Dictionary
                                   {
                                       {Command.Go, new GoHandler()},
                                       {Command.Pause, new PauseHandler()},
                                       {Command.Stop, new StopHandler()}
                                   };
        }

        public void DoSomethingWithTheSwitchStatement(Command command)
        {
            _commandHandlers[command].Handle();
        }
    }

Ok this is a big improvement from our previous switch statement it helps us get a bit closer to our S.O.L.I.D code Nirvana by adhering to our single responsibility principle and encapsulating our logic in specific handlers. However if we need to add a new handler we will need to modify the code by adding a new handler to the dictionary which violates our Open Closed Principle.

StructureMap To The Rescue!

The first thing we need to do is modify our ICommandHandler interface slightly.

public interface ICommandHandler
{
        void Handle();
        bool Handles(Command command);
        bool IsDefault { get; }
}

We have added two methods to the Interface. The new Handles method means each concrete implementation can now return whether or not it can handle a specific Command and the IsDefault property tells us whether or not our Handler is the default handler or not.

Our concrete implementation would now look like this:

    public class GoHandler:ICommandHandler
    {
        public void Handle()
        {
            Console.WriteLine("Go");
        }

        public bool Handles(Command type)
        {
            return Command.Go == type;
        }

        public bool IsDefault
        {
            get { return false; }
        }
    }

Now our class that can take an IEnumerable collection of  ICommandHandlers and query the collection for a handler that can handle the particular command.  It can also query the collection for the default handler if there is no handler defined for the particular Command.

Our class that originally contained the switch statement now looks like this:

    public class RefactoredWithStructureMap
    {
        private readonly IEnumerable _commandHandlers;

        public RefactoredWithStructureMap(IEnumerable commandHandlers)
        {
            _commandHandlers = commandHandlers;
        }

        public void DoSomethingWithTheSwitchStatement(Command command)
        {
            var defaultHandler = _commandHandlers.Where(handler => handler.IsDefault).First();

            var commandHandler = _commandHandlers
                .Where(handler => handler.Handles(command))
                .DefaultIfEmpty(defaultHandler)
                .FirstOrDefault();

            commandHandler.Handle();
        }
    }

Great but we need to make one more change so that we can get StructureMap to inject in our Handlers. We Need to modify our StructureMap Registry to do two things. Firstly we need to tell StructureMap to load all implementations of ICommandHandler. Secondly we need to tell StructureMap how to satisfy any requests for IEnumerable<ICommandHandler> and how to construct that collection.

To do this we need to add the following lines to our Registry.

    internal class StructureMapRegistry : Registry
    {
        public StructureMapRegistry()
        {
            Scan(scanner =>
                     {
                         scanner.TheCallingAssembly();
                         scanner.WithDefaultConventions();
                         scanner.AddAllTypesOf();
                     });

            ForRequestedType>()
                .TheDefault.Is.ConstructedBy(x => ObjectFactory.GetAllInstances());
        }
    }

The beauty of this approach is now if we need to add a new handler all we have to do is write a new handler and it will automatically be injected into our class by StructureMap!

kick it on DotNetKicks.com

Tags: ,
Posted in .NET, S.O.L.I.D | No Comments »

One Tangible Benefit of S.O.L.I.D Development

Saturday, May 16th, 2009

So S.O.L.I.D development seems to be the new buzz word at the moment. Now even though we all know that code that is loosely-coupled and highly cohesive leads to greater maintainability and  testability, sometimes it is difficult to tangibly measure the benefits that well structured code can actually bring to the business.

For this post I’m going to mainly concentrate to on the first two rules of S.O.L.I.D development namely the Single Responsibility Principle and the Open Closed Principle

A code base that follows the S.O.L.I.D principles will typically have the following characteristics:

Now when I contrast this with the very typical, legacy code base that I am currently working with things are very different.

Where I’m working currently we have a large team working on a number of concurrent projects all working in the same code base. Because of the way our code is structured we typically have a lot of problems merging our code because there are many classes that have to much responsibility, do too much and know about too many other classes. This means that the same classes time after time are modified for different projects. This in turn causes us far more merge conflicts when trying to reintegrate our code. Now problems merging code means longer project timelines and increased costs to the customer.

When S.O.L.I.D principles are adhered to the way we write code is far different. To add functionality to our system we normally try to achieve this by adding new code and classes rather than modifying existing code (Open Closed Principle – where our system is open for extension but closed for modification). Typically because our classes do less and are smaller the chances of two projects working on the exact same class is also reduced, thus reducing the chances of merge conflicts.

S.O.L.I.D and good OO design principles in your code are  not just wooly concepts banded around by academic types but are good sound principles that can save your organization time and money in the long run.

kick it on DotNetKicks.com

Posted in .NET, S.O.L.I.D, Software Architecture | No Comments »