I recently released a new course on MonoTouch at Pluralsight.

I wanted to take a bit of time here to talk about MonoTouch and to tell you why you should be using it instead of developing iOS applications in Objective-C

Flipping directions

When I first started developing with iOS, I firmly believed that the job should be done using the tools that Apple provided.

I still think it is a very good idea to learn Objective-C and how to develop an iOS application using Objective-C and XCode.

But I am convinced now that overall MonoTouch is the way to go.

Objective-C is a decent language, but it has a fairly steep learning curve for a C# or Java developer.  XCode, the IDE for developing iOS applications, is a decent IDE, but it is not nearly as powerful as MonoDevelop or Visual Studio.

The reality of the situation is that Apple’s development platform is still back in 1990.  Even though there have been some changes and growth, I firmly believe now that Objective-C and the underlying technology cannot ever catch up to .NET or Java.

I don’t say this lightly.  As I said, before I developed a fairly large application in Objective-C.  I authored a Pluralsight course on iOS development with Objective-C.  I was pretty convinced this was the way to go until I gave MonoTouch a try.

An unfair test

I really gave MonoTouch an unfair test, but it passed anyway.  I set out to learn, configure, build a MonoTouch application, and deploy it to the Apple App Store in 1 weekend.

I figured if MonoTouch could pass this test then I would immediately save more than the $400 cost for the software since the next application I was going to build was going to probably take at least a week worth of time to build in Objective-C.

MonoTouch easily passed my test and really exceeded my expectations.

The main advantage

By and far the main advantage in using MonoTouch is the language.

C#’s ability to wire up events through event handlers and delegates makes working with iOS so much easier.

There are many situations in iOS where you have to create a special class to act as a delegate for providing behavior for various iOS controls and classes.  In C#, many of these delegate classes can be replaced by a C# delegate or lambda expression.

Another really painful situation in Objective-C is memory management.  If you aren’t used to tracking memory usage it takes a bit to get adjusted to it in Objective-C.  Sure, it really isn’t that hard, but once I started working with C# to build my iOS application, I realized how much faster I could fly through the code without having to even think about it.  (The newer version of Objective-C has somewhat built in memory management, but it is not a true garbage collection implementation.)

Along with C#, you get the full power of the .NET framework.  Almost all of the base class libraries from .NET are available in MonoTouch.  (You basically have the silverlight .NET profile.)

This really comes in handy in 3 main areas:

• Working with XML
• Working with databases
• Calling web services

If you try to do these things in Objective-C, it is possible, but it will hurt like hell.

Give it a shot

If you are interested in developing iOS applications and you haven’t tried MonoTouch, go give it a try.  Trust me, it is worth the effort.  One of the big factors that had me developing Android applications and shying away from iOS was the hurdle of trying to learn and work with Objective-C.

MonoTouch lets you reuse your C# skills without any extra overhead, since the application is compiled down to native ARM assembly code.

If you don’t know where to get started or want to learn a little bit more about MonoTouch, feel free to check out my course on Pluralsight.

Kudos to the Xamarin team for building such a great product!

(BTW, that photo is me flipping.  Actually it is a thing I used to call “throwing myself at the ground for dramatic effect.”)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

There is one major problem that I have been running into though.  Switch statements and dictionaries are not functionally equivalent for one major reason…

Switches allow for default

I kept struggling with this when I would implement a dictionary to replace a switch.  How can I deal with the default case?

There are of course many ways to deal with the default case in a dictionary or map, but I didn’t really like any of the solutions because they either required me to remember to check to see if my entry was in the dictionary before looking it up, or to rely on catching an exception.

Let me give you an example:

switch(vegetables)
{
	case Vegetables.Carrot:
		DoCarrotStuff();
		break;

	case Vegetables.Spinach:
		EatIt();
		break;

	case Vegetables.Peas:
		FeedToDog();
		break;

	default:
		Butter();
		Salt();
		SprinkleCheese();
		Eat();
}

Converting this to a dictionary we get something like:

var vegetableActionMap = new Dictionary<Vegetable, Action>
{
	{ Vegetable.Carrot, () => DoCarrotStuff() },
	{ Vegetable.Spinach, () => EatIt() },
	{ Vegetable.Peas, () => FeedToDog() }
}

Action result;
if(!vegetableActionMap.TryGetValue(vegetable, out result)
{
     Butter();
	  Salt();
     SprinkleCheese();
     Eat();
}
else
   result();

So clunky, just to handle the default case.

Would be much better do something like this:

var vegetableActionMap = new Dictionary<Vegetable, Action>
{
	{ Vegetable.Carrot, () => DoCarrotStuff() },
	{ Vegetable.Spinach, () => EatIt() },
	{ Vegetable.Peas, () => FeedToDog() }
}.WithDefaultValue( () => { Butter(); Salt(); SprinkleCheese(); Eat(); });

vegetableActionMap[vegetable]();

Well now you can!

Enter DefaultableDictionary!

Also the first thing I ever put on GitHub!

The idea is pretty simple, I am just creating a decorator for IDictionary.

The DefaultableDictionary has a constructor that takes an IDictionary and a default value.

It then delegates all of the methods to the passed in IDictionary reference.  For the methods that look up a value, it handles returning the default if the key doesn’t exist in the dictionary.

I created an extension method that lets you just put a .WithDefaultValue() on the end of your dictionary declaration in order to auto-magically give you a DefaultableDictionary back with that default value.

Sleep well my friend

Knowing that you can not create a dictionary that has a default value which is returned instead of throwing an exception if the key passed in is not found.

I have no doubt that in 3rd world countries children are still starving, but in 1st world countries children with VS Express hacking away at iPhone applications using MonoTouch will not have to catch exceptions from dictionaries that do not know how to just return a default value.

So now there is no excuse!  Refactor those switches!

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I consider var to actually be quite a useful language feature to reduce repetition and make your code slightly more flexible for refactoring, but I’ve always had one little problem with it.

What if I want a base class type or interface?

I most often run into this problem when I am working with lists.

Have you ever written some code like this?

var myList = new List<int>();

The problem with this code is that we are stuck with the concrete List implementation for our variable myList, because we don’t have a way of specifying that we actually want an IEnumerable to be our reference type.

The solution is so simple that I am a bit surprised I didn’t think of it earlier.

I had always assumed that I just couldn’t use var there and would have to declare the type like so:

IEnumerable<int> myList = new List<int>();

But we can actually just use as to keep our var in place if we want to.

var myList = new List<int> as IEnumerable<int>

So it’s actually a little more verbose, but I think it is a bit more clear, and it is more consistent if you are using var everywhere else.

There has to be a better use

I’ve been racking my brain trying to come up with more useful ways to use this little combo, but I can’t really seem to come up with anything.

It seems like there has to be something else you could use this combo for.

What do you think?  Any ideas?

Here is the original code.

public static DataFileParser GetParser(DataFile dataFile)
{
    switch ((FileType)dataFile.ValidationFormat.FileType)
    {
        case FileType.PDF:
            return new PdfParser(dataFile);
        case FileType.Image:
            return new ImageParser(dataFile);
        case FileType.CsvWithHeaderRow:
            return new CsvParser(dataFile, true);
        case FileType.Csv:
            return new CsvParser(dataFile, false);
        default:
            throw new NotImplementedException("There is no parser for " + 
dataFile.ValidationFormat.FileType.ToString());
    }
}

Surprisingly simple solution

Try and say that 3 times fast.

I thought about this a bit and at first was having a hard time coming up with a solution.  Then I typed the code into an editor and realized how easy it is.

The trick here is that it looks like something other than the simple case of data mapping to logic, but it isn’t.

• The logic in this case is the creation of the Parser. 
• The data is the file type.

Once you think of it in those terms you can easily solve it using the pattern I mention in my previous post on the subject. 

Switch be gone!

private static Dictionary<FileType, Func<DataFile, DataFileParser>> DataFileTypeToParserCreatorMap = 
    new Dictionary<FileType, Func<DataFile, DataFileParser>>()                                                                                            
{ 
    {FileType.PDF, file => new PdfParser(file)},
    {FileType.Image, file => new ImageParser(file)},
    {FileType.CsvWithHeaderRow, file => new CsvParser(file, true)},
    {FileType.Csv, file => new CsvParser(file, false)}
};

public static DataFileParser GetParserRefactored(DataFile dataFile)
{
    Func<DataFile, DataFileParser> parserCreator;
    if(!DataFileTypeToParserCreatorMap.TryGetValue(
                             dataFile.ValidationFormat.FileType, 
                             out parserCreator))
        throw new NotImplementedException("There is no parser for " +
            dataFile.ValidationFormat.FileType.ToString());

    return parserCreator(dataFile);
}

That is the quickest solution that preserves the existing code as much as possible.

Another solution

With the first solution we pushed the object creation into the map.

If we can make the constructor for all the parsers the same, we can use reflection to dynamically create our instances by looking up the type in the dictionary.

In this example, I assume that we have refactored CsvParser to have a constructor that only takes one parameter and internally sets a value of usesHeader to false, and we have created a CsvWithHeaderParser that inherits from the CsvParser and sets usesHeader to true.

private static Dictionary<FileType, Type> DataFileTypeToParserTypeMap = new Dictionary<FileType, Type>()
{
    { FileType.PDF, typeof(PdfParser)},
    { FileType.Image, typeof(ImageParser)},
    { FileType.CsvWithHeaderRow, typeof(CsvWithHeaderParser)},
    { FileType.Csv, typeof(CsvParser)}                 
};

public static DataFileParser GetParser(DataFile dataFile)
{
    Type parserType;
    if(!DataFileTypeToParserTypeMap.TryGetValue(
            dataFile.ValidationFormat.FileType, 
            out parserType))
        throw new NotImplementedException("There is no parser for " +
                    dataFile.ValidationFormat.FileType.ToString());

    return (DataFileParser) Activator.CreateInstance(parserType, dataFile);
}

Pretty similar solution.  I prefer the first though for several reasons:

• The refactor is localized, where the second solution has to touch other classes.
• Reflection makes you lose compile time safety.
• You may create a new parser that you want to have more parameters for the constructor.  With the second solution, you will have a hard time doing that.
• The first solution gives you ultimate flexibility in setting up the constructor of the parser.  If you wanted to do 5 steps for a particular parser, you could.

Anyway, next time you run into a switch statement that is hard to figure out how to refactor, try to break it into a mapping between data and logic.  There is always a solution.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Someone mentioned in the comments that it wasn’t very clear exactly what was going on with the final code.  I tend to agree that this:

LogOnError(_riceCooker.Cook);

… is not very clear.

Really, there are two problems with this code that I can see.

1. It is not clear what this is going to do or whether or not LogOnError or Cook is the method we are concerned about.
2. It’s not very self-discoverable at all.  If we had a library of useful wrapper methods like these, we wouldn’t have a good intellisense way to know what they are.

I can solve both of those issues, but doing so starts to move us into a weird zone where I am not quite sure I feel comfortable.  But, nevertheless, in the name of science…

Let’s start backwards

Liking fluent interfaces, here is the kind of syntax that I would prefer to be able to use:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

It is a little bit longer syntax, but I like it for a few reasons:

1. It clearly indicates what is going on here.  We are wrapping a method call using a wrapper.  We are wrapping with a method called LogOnError.
2. You get intellisense all the way.  The correct implementation of this, should let me Type With + ‘.’ and then see a list of all the possible wrapping methods I have implemented.  This makes the wrapping set of methods self-discoverable.

I really like the idea of being able to easily change the functionality of the wrapping just by changing the last part of the line.  For example, if we had implemented a wrapping method that was LogAndAbortOnError(), we could change our code to use that pretty easily.

Wrapper.Wrap(_riceCooker.Cook).With.LogAndAbortOnError();

If we implement this correctly, intellisense will give us our options.

Making it so

Creating a fluent syntax in C# can often involve quite a bit of magic and voodoo.  I always like to gather my reagents before embarking on such a journey.

So grab a live chicken, a stapler, and a sharp knife and let’s go!

First step, let’s simplify this.  The With is nice, but it is just for flow, we don’t really need it.  So let’s figure out how to implement our syntax without the With and add it in afterwards.

Wrapper.Wrap(_riceCooker.Cook).LogOnError();

First the easy way.

1. Create a static Wrapper class with a Wrap method that takes an Action and returns an Action.  (We’ll use this to convert whatever we pass in to an Action, so that we can use a Lambda expression or any method call there.)
2. Create a static extension method that operates on an Action.  Call it LogOnError.

public static class Wrapper
{
    public static Action Wrap(Action action)
    {
        return action;
    }
        
    public static void LogOnError(this Action action)
    {
        try
        {
            action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }
}

Not too bad.  Not a large amount of magic going on here.  Just using an extension method.

But, we already have a problem.  Using a plain old Action is going to give us too many choices in the intellisense drop down.  It could make it hard to know what our real options are and when we try and add the With syntax later, we will need to use a property off of an object we return from the Wrap method.

Making it better

We can fix this by actually wrapping the Action with a custom type that we can add our methods to.

Instead of Wrap returning an Action, it will return a WrappedAction.

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() {Action = action};
    }
        
    public static void LogOnError(this WrappedAction wrappedAction)
    {
        try
        {
            wrappedAction.Action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }

    public class WrappedAction
    {
        public Action Action { get; set; }
    }
}

Looking better.  Now when we put a ‘.’ at the end of our Wrap call we only see LogOnError as an option.

We can be sure now that if we create an extension method for a WrappedAction, we will make sure that method is self-discoverable.  Before, the generic Action extension  method could make our method show up places that we don’t want it to and can get lost in the other methods on Action.

Making it done

The last thing we need to do is add the With.

Ideally, when we hit the ‘.’ on the end of the Wrap method, we want to see With as an option.  When we hit the ‘.’ on the end of the With property, we want to see LogOnError as an option.

In order to accomplish this we need to:

1. Add a With property to the WrappedAction.
2. Have the With property be of a new type (WrappedActionTarget) so that we can add our extension methods for that new type.
3. Change the extension method to operate on the new type.

Here is what we end up with:

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() { Action = action };
    }

    public static void LogOnError(this WrapperMethodTarget target)
    {
        try
        {
            target.WrappedAction.Action();
        }
        catch (Exception)
        {
            Console.Write("Logging this error");
        }
    }
}

public class WrapperMethodTarget
{
    public WrappedAction WrappedAction { get; set; }
}

public class WrappedAction
{
    public Action Action { get; set; }

    public WrapperMethodTarget With
    {
        get
        {
            return new WrapperMethodTarget() { WrappedAction = this };
        }
    }
}

Now we can use the syntax of:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

We can move that LogOnError method out to another class, or create new extension methods somewhere else.  I just put it in there to avoid creating another class.

Is this really practical?

I don’t know.  To be honest, I was playing around with creating extension methods that work on Actions and I came up with this way to use them.

I could see making a wrapping library that had different kinds of ways you would wrap method calls built into it.  It could allow you to specify how you log in a configuration and then you would get all of this common stuff automatically.

Even if it is not practical, it’s pretty fun, and it demonstrates the power of Action, or rather functional programming in general.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It is a little difficult to implement though.

To be honest, I don’t think I’ve ever really seen it successfully implemented.  I mean sure, I’ve seen examples of how you could use it for “cross-cutting” concerns like logging.

The problem is it is usually pretty difficult to use, and the only real practical application I can ever come up with is logging.  I know, it is probably just my lack of knowledge in the area, but if you bear with me I’ll show you a neat little trick you can use to address cross-cutting concerns by doing something similar to what AOP does using Action<>.

Putting it all in one place

The main problem AOP tries to solve is taking aspects of your software that exist in many different places and condensing them into one place for you to maintain.

Exception handling and logging tend to be the most infamous of these cross-cutting concerns.  Many places in your code you no doubt have many instances where you catch an exception and the only thing you can really do is log it.

I’m going to show you a little easy way to do that using Action<>.

Giving credit where credit is due, I got this idea from some code that a coworker of mine, Subha Tarafdar, wrote.  (He is a genius.)

He wrote some code to basically do what I am going to show you, but with retrying database queries.  He was able to reduce many places in the code base where we had repeated logic to retry executing database queries when getting a deadlock or timeout.

Does this code belong to you?

public void MakeRice()
{
    try
    {
        _riceCooker.Cook();
    }
    catch (Exception exception)
    {
        // Don't care if this fails,
        // there is nothing we can do about it.
        Logger.Log(exception.Message);
    }
}

Ignore that I am catching a general exception here.  It is a bad practice, but sometimes all you are going to do is log whatever bad thing happens and move on.

It’s pretty common to do something in a try block and catch an exception only to log it.

Think about how many times this code or something similar to it might be sprinkled throughout your code base.

Action<> to the rescue

If you’re not familiar with Action<> take a look at this post I did that gives a very simple explanation for how it works.

We can take the logic of the try, catch, and log exceptions and put it into a method that only varies by what action we do.

public static void LogOnFailure(Action action)
{
    try
    {
        action();
    }
    catch (Exception exception)
    {
        Logger.Log(exception.Message);
    }
}

I’m not a big fan of static methods but in certain cases they make sense.  The alternative is to have all of this code sprinkled throughout your code base.

Now that we have this method, we can do anything we want and know that if there is an error it will be logged.

Check this out:

LogOnFailure(_riceCooker.Cook);
LogOnFailure(KickACat);
LogOnFailure(() =>
                    {
                        Wakeup();
                        SmellTheRoses();
                    }
            );

And if you decide you want to change how you log the error or what you do on it, you can change it all in one place.

Not just for logging

You can apply this kind of solution in many places where you have cross cutting concerns in your code base.

Here are a few suggestions for places you might consider this kind of a solution:

• Retrying on failure logic
• Using an alternative service for a failure (web service “A” failed, but we can use web service “B”)
• Database connection and connection closing logic.  (Open connection, do something, close connection.)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It is a shame that many developers shy away from them, because they don’t really understand them.

Adding Action<> and Func<> to your toolbox is a very important step in improving your C# code.

It’s not really that hard to understand what they do and how to use them, it just takes a little patience…

A simple way of thinking about Action<>

Most of us are pretty familiar with finding sections of repeated code, pulling that code out into a method and making that method take parameters to represent the differences.

Here is a small example, which should look pretty familiar:

public void SteamGreenBeans()
{
    var greenBeans = new GreenBeans();
    Clean(greenBeans);
    Steam(greenBeans, Minutes.Is(10));
    Serve(greenBeans);
}

public void SteamCorn()
{
    var corn = new Corn();
    Clean(corn);
    Steam(corn, Minutes.Is(15));
    Serve(corn);
}

public void SteamSpinach()
{
    var spinach = new Spinach();
    Clean(spinach);
    SteamVegetable(spinach, Minutes.Is(8));
    Serve(spinach);
}

Each one of these methods pretty much does the same thing.  The only difference here is the type of vegetable and the time to steam it.

It is a simple and common refactor to refactor that code to:

public void SteamGreenBeans()
{
   SteamVegetable(new GreenBeans(), 10);
}

public void SteamCorn()
{
    SteamVegetable(new Corn(), 15);
}

public void SteamSpinach()
{
    SteamVegetable(new Spinach(), 8);
}

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Steam(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

Much better, now we aren’t repeating the “actions” in 3 different methods.

Now let’s imagine we want to do something more than steam.  We need to be able to fry or bake the vegetables.  How can we do that?

Probably we will have to add some new methods for doing that.  So we will end up with something like this:

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Steam(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

public void FryVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Fry(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

public void BakeVegetable(Vegetable vegetable, int timeInMinutes)
{
   Clean(vegetable);
   Bake(vegetable, Minutes.Is(timeInMinutes));
   Serve(vegetable);
}

Hmm, lots of duplication again.  No problem.  Lets just do what we did to the first set of methods and make a CookVegetable method.  Since we always clean, then cook, then serve, we should be able to just pass in the method of cooking we will use.

Oh wait, how do we do that?  We can’t just extract out Bake or Fry or Steam, because the Bake, Fry and Steam methods are logic and not data.

Unless… unless we can make them data.  Can we do that?

We sure can, check this out:

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Steam, timeInMinutes);
}

public void FryVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Fry, timeInMinutes);
}

public void BakeVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Bake, timeInMinutes);
}

public void CookVegetable(Vegetable vegetable,
   Action<Vegetable, CookingTime> cookingAction,
   int timeInMinutes)
{
    Clean(vegetable);
    cookingAction(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

We got rid of the duplicated code the same way we did when we did our first refactor, except this time we parameterized method calls instead of data.

If you understood this, you understand Action<>.  Action<> is just a way of treating methods like they are data. Now you can extract all of the common logic into a method and pass in data that changes as well as actions that change.

Congratulations, you are doing the strategy pattern without having to create an abstract base class and a huge inheritance tree!

So when you see Action<>, just think “ah, that means I am passing a method as data.”

It really is as simple as that.

Action<Vegetable, CookingTime> translated to English is: “A method that takes a Vegetable and a CookingTime as parameters and returns void.”

What about Func<>?

If you understand Action<>, you understand Func<>.

Func<X, Y, Z> translated to English is: “A method that takes an X, and a Y as parameters and returns a Z”.”

The only difference between Action<> and Func<> is that Func<>’s last template parameter is the return type.  Func<>s have non-void return values.

Bonus: Predicate<> is a Func<> that always returns a boolean.

That’s all there is to it.  There really isn’t a need to know much more than that to make sure of Action<> and Func<> in order to start using them.

If you are interested in some other ways to apply Action<> and Func<>, here are some posts I have written which focus on them.

• Pulling out the Switch: It’s Time for a Whooping
• Parsing Columns Like a Ninja
• The Power of Func<>
• Super Combo: Map + Function Pointer

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I talked about refactoring helper classes before, but this is slightly different.

In this case I want to talk about refactoring classes that you want to keep around, but have all or many static members.  A good example of this is some kind of service class that returns data from the database.

It’s not always very clear whether that kind of class really is some sort of helper class.  It is a bit of a judgment call.  If you do find a helper class though, don’t just leave it there.

So, basically if you have determined the class you are working with is going to stay, but it does have static methods and you need to get rid of them, because you are doing dependency injection or mocking, read on.

Defining the two approaches

What do I mean by step-wise refactoring?

Here is the basic outline of the first approach:

1. Make the method you need to be non-static, non static.
2. Add an interface with just that one method in it.
3. Implement the interface.
4. Change the references to that method to use the interface instead.

Let’s take a look at an example:

public static class LostOrderService
{
    public static IEnumerable<Orders> GetLostOrders(int customerId)
    {        
    }

    public static IEnumerable<Customer> GetCustomerWithLostOrders()
    {
    }
}

If we are interested in the GetLostOrders method, we can apply steps 1-3 to get:

public interface ILostOrderService
{
    IEnumerable<Orders> GetLostOrders(int customerId);
}
    
public class LostOrderService : ILostOrderService
{
    public IEnumerable<Orders> GetLostOrders(int customerId)
    {        
    }

    [Obsolete("If you touch this refactor to make it not static. 
                      Be a man, do the right thing.")] 
    public static IEnumerable<Customer> GetCustomerWithLostOrders()
    {
    }
}

Now we can go in and change references in our code for just that one method.

public void ProcessLostOrders()
{
    var orders = LostOrderService.GetLostOrders(_customerId);
    foreach(var order on orders)
    {
        ReprocessOrder();
    }

}

// Refactored becomes:

public void ProcessLostOrders(ILostOrderService lostOrderService)
{
    var orders = lostOrderService.GetLostOrders(_customerId);
    foreach(var order on orders)
    {
        ReprocessOrder();
    }

}

Now let’s look at the 2nd technique, wrapping and delegating.  Here is the outline of the wrapping and delegating approach:

1. Create a wrapper class that’s going to be used to wrap the static classes calls.
2. Implement all the methods in the static class as non-static methods in the wrapper class.  Each method just delegates to the static method in the static class.
3. Create an interface which contains all the methods.
4. Have the wrapper class implement the interface.

Here is an example of doing it this way, given the same original code as the first example:

public interface ILostOrderService
{
    IEnumerable<Orders> GetLostOrders(int customerId);
    IEnumerable<Customer> GetCustomerWithLostOrders()
}

public class LostOrderServiceWrapper : ILostOrderService
{
    public IEnumerable<Orders> GetLostOrders(int customerId)
    {      
        LostOrderService.GetLostOrders(customerId);
    }

    public IEnumerable<Customer> GetCustomerWithLostOrders()
    {
        LostOrderService.GetCustomerWithLostOrders();
    }
}

The references to the LostOrderService will be refactored exactly the same as in the first example, so I won’t include it here.

You can see in this example, we didn’t touch LostOrderService itself.  Except, you probably want to put an Obsolete attribute on the class to tell users to not use this, but use the wrapper class instead.

Which is more bettah?

I’ve tended to use the wrapping and delegating approach in the past, but I am starting to think the step-wise approach is better for a few reasons.

• The step-wise approach is a bit more obvious to someone later using the class.  When you wrap and delegate, someone has to know there is a wrapper class.  With the step-wise approach, there is no choice.
• With the step-wise approach, you are actually getting rid of the bad and evil static methods.  When you wrap and delegate, you are still leaving them there, just hiding them behind a wrapper.

To me, the wrapping approach feels more like I am working around things rather than cleaning them up.  I also feel like someone can see what I started and pick it up from there step-by-step.  Where with the wrapping approach, the mess may never get cleaned up, because there is a workaround.

Where wrap and delegate shines

There is a place that wrap and delegate wins hands down though.

If you don’t have control over the source code of the static class or static calls, you cannot do the step-wise approach.

The wrap and delegate approach can be a lifesaver when you are dealing with static references in your code to an external library that you can not change.  You can simply wrap the external library calls and instead reference the wrapper in your code.  Now you can actually unit test that code.

Anytime you are using an external library, you should consider putting some kind of protective wrapper around it.  You never know when you may want to replace it or upgrade the library.  You don’t want to go hunting through all your code looking for references.

So, while either way will work, I prefer to use the step-wise method if I have access to the source code of the static class.

What do you think?  Do you have any other solutions?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Today I am going to show you how to refactor the switch statements to alleviate that problem.

There are some varied opinions on refactoring switch statements which I believe derive from trying to treat all switch statements as the same.  I want to look at the kinds of switch statements that exist and why I recommend to refactor each one in a particular way.

Data to data

The first most obvious kind of switch statement is one that maps one form of data to another form of data.

switch (state)
{
    case "Florida": return "Tallahassee";
    case "Idaho": return "Boise";
    case "Arizona": return "Phoenix";
    case "South Carolina": return "Columbia";
}

This example is clearly mapping one piece of data to another.  The best refactor for this situation is to use a map.  In C# it is a dictionary, in Java a map.

var stateToCapitolMap = new Dictionary<string, string>()
{
    {"Florida", "Tallahassee"},
    {"Idaho", "Boise"},
    {"Arizona", "Phoenix"},
    {"South Carolina", "Columbia"}
};

return stateToCapitolMap[state];

I cannot believe how many people argue against this refactoring.  It doesn’t look like much, but we have greatly separated logic from data and increased the maintainability of the code.

Before our refactoring, consider, how you would be able to read all the states and capitols from a file and insert them into the switch statement?  The only possible way would be through code generation.  Clearly this indicates a coupling of code and data.  The switch statement is formatted in such a way that it almost looks like data, but don’t let that fool you, it is code.

Consider the refactored example.  If we want to read the values from a file, it is simple.  So simple, that I’ll even show the code right here.

var stateToCapitolMap = new Dictionary<string, string>();
foreach (string line in File.ReadAllLines("StatesAndCapitols.txt"))
{
    string[] stateCapitol = line.Split(',');
    stateToCapitolMap.Add(stateCapitol[0], stateCapitol[1]);
}
return stateToCapitolMap[state];

Data to action

This kind of switch statement appears different than data to data, but it is actually very similar.  In this case we are mapping some data to a direct action that should be performed given that data.

Often this form of logic can be disguised by multiple actions happening in a case statement.

switch (move)
{
    case "Up": MoveUp();
        break;
    case "Down": MoveDown();
        break;
    case "Left": MoveLeft();
        break;
    case "Right": MoveRight();
        break;
    case "Combo":
        MoveUp();
        MoveUp();
        MoveDown();
        MoveDown();
        break;
}

We can take the same approach here because really this is a form of mapping data to data.  The second data item is essentially the name of a method to call to perform an action.  We can illustrate this intent easily in C#.  (In Java, you will need to wrap the action into a set of classes with a common interface.)

var moveMap = new Dictionary<string, Action>()
{
    {"Up", MoveUp},
    {"Down", MoveDown},
    {"Left", MoveLeft},
    {"Right", MoveRight},
    {"Combo", () => { MoveUp(); MoveUp(); MoveDown(); MoveDown(); }}
};

moveMap[move]();

What we are essentially doing now is a dynamic look-up of the method to call based on the data.  We could even make this example data driven from a text file that specified how to map a move to a method name or list of method names, but that is far beyond on the scope of this post, and I don’t think I would recommend it unless you have a really good reason.

Data to multiple actions

If you are familiar with the techniques of refactoring switch statements, you make be shaking your head by now saying “that guy is wrong, he needs to use a factory.”  Okay, well now we are going to do it.

In the data-to-action refactoring, I opted for the simplest solution that can work, instead of trying to over solve the problem by adding complexity in the form of a factory.

But, what happens when you have multiple switch statements in your code that operate on the same set of data?

switch (move)
{
    case "Up": MoveUp();
        break;
    case "Down": MoveDown();
        break;
    case "Left": MoveLeft();
        break;
    case "Right": MoveRight();
        break;
    case "Combo":
        MoveUp();
        MoveUp();
        MoveDown();
        MoveDown();
        break;
}

// ... somewhere else

switch (move)
{
    case "Up":
        moveName = "Basic Up Move";
        break;
    case "Down":
        moveName = "Basic Down Move";
        break;
    case "Left":
        moveName = "Basic Left Move";
        break;
    case "Right":
        moveName = "Basic Right Move";
        break;
    case "Combo":
        moveName = "Up Up Down Down Combo Move";
        break;
}

Sure, we could refactor these both into maps or dictionaries.  But what will happen when we try and add a new move?  We’ll have to remember to add logic in both places or we’ll have a problem.  In the prior example we recognized that data was being mapped to an action, so we represented that as succinctly in code as possible.

In this example, the same data is being mapped to some data that describes a move and actions to perform.  We need some way to house these attributes that belong to the data we are switching on together, and we would like to have this all in one place, so we don’t have to change the code in multiple places.

Our best solution here is to use a factory that gives us the right kind of object that implements the behavior that should be tied to the data we are currently switching on.

public interface IMove
{
    void DoMove();
    string GetFriendlyName();
}

public class UpMove : IMove
{
    public void DoMove()
    {
        // Do the move
    }

    public string GetFriendlyName()
    {
        return "Basic Up Move";
    }
}

public static class MoveFactory
{
    private static Dictionary<string, Func<IMove>> moveMap = new Dictionary<string, Func<IMove>>()
    {
        {"Up", () => { return new UpMove(); }},
        {"Down", () => { return new DownMove(); }},
        {"Left", () => { return new LeftMove(); }}
        // ...
    };

    public static IMove CreateMoveFromName(string name)
    {
        return moveMap[name]();
    }
}

You can see here that we are creating a factory which contains a dictionary which maps a move name to what kind of object to create.  Each move implements a common IMove interface.  (I only show some of the implementation here.)

Now in our code we can replace those switch statements with polymorphic behavior from our object returned from the factory.

IMove move = MoveFactory.CreateMoveFromName(name);
move.DoMove();
String friendlyName = move.GetFriendlyName();

The nice thing about this implementation is that if we try to add a new move the IMove interface will require us to implement all the proper methods.  We make a change in one place and the compiler reminds us what we need to do.

Don’t jump straight to the factory

You may have heard the argument between using a factory or a dictionary for refactoring switch statements before.  What I am trying to show in this blog post is that it depends on your situation.

The simplest solution is a dictionary or map.  Once you have a second place you are mapping the same data, you should move to a factory.  The factory then contains the mapping between a piece of data and a class.

I also wanted to note here that I didn’t use enumerations.  In real code you should.  I avoided them here to prevent adding one more layer of abstraction so that my example would not require as much explanation.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

public void CreateFromLine(string line)
{
    var columns = line.split(',');

    this.Name = StripQuotes(columns[0]);
    this.Description = StripQuotes(columns[1]);
    this.Category = StripQuotes(columns[2]);
    this.Stuff = StripQuotes(columns[3]);
    this.MoreStuff = StripQuotes(columns[4]);
    if (columns.Count > 5)
        this.EvenMoreStuff = StripQuotes(columns[5]);
}

Or some code like it.  It is pretty common to parse a line and then take each column and store it in your object as data.

One of the annoying problems is that if you have optional columns you have to check to see if they are there before you can parse them.

You’re also repeating your code to strip the quotes off, or whatever other preprocessing you are doing, all over the place.

I know you can use a data driven approach to specify column to property mappings, but I wanted a really low tech, simple solution.

I finally came up with one using one of my favorite C# constructs.

Action<> is superb for solving these kinds of problems

See if this code makes you feel any better:

var propertySetters = new List<Action<string>>
{
    value => this.Name = value,
    value => this.Description = value,
    value => this.Category = value,
    value => this.Stuff = value,
    value => this.MoreStuff = value,
    value => this.EvenMoreStuff = value
};

var columns = line.split(',');

foreach (int columnNumber = 0; columnNumber < columns.Count; columnNumber++)
{
    var propertySetter = propertySetters[columnNumber];
    propertySetter(StripQuotes(columns[columnNumber]);
}

It may not seem like much.  It is not really a reduction in code, but we have done a few important things here.

• Removed the explicit handling of optional columns, since we are now only populating columns that exist.  (Adding a new optional column is as easy as adding one more line to the list.)
• Removed the responsibility from the code of explicitly tracking the column numbers.  Column number mapping now is implicit by the order of the columns in the list.
• Removed the hidden code duplication of having calls to StripQuotes repeated for each column.
• Separated the mapping of properties to columns from the assignment of them.

That last point deserves a little more explanation.  Why do we care if we have separated the mapping of properties to columns from the assignment?

The answer is not obvious until you try and use this same code to handle a different set of columns, or columns in a different order.

By separating out the mapping, we can pass the assignment code a different set of mappings, and it will still work.

This allows us to reuse the logic we have in the assignment of the columns to properties instead of rewriting it for other column to property mappings or orderings.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.