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.

I’m going to go against the grain here today though and tell you that it is not always required.

Many times code that should be refactored doesn’t get refactored due to the myth that you must always have unit tests in place before refactoring. 

In many cases the same code stays unimproved over many revisions because the effort of creating the unit tests needed to refactor it is too high.

I think this is a shame because it is not always necessary to have unit tests in place before refactoring.

Forgoing the safety net

If you go to the circus, you will notice that some acts always have a safety net below because the stunt is so dangerous that there is always a chance of failure. 

You’ll also notice that some acts don’t have a safety net, because even though there is risk of danger, it is extremely small, because of the training of the performers.

Today I’m going to talk about some of the instances where you don’t necessarily need to have a safety net in place before doing the refactor.

Automatic refactorings

This is an easy one that should be fairly obvious.  If you use a modern IDE like Visual Studio, Eclipse, or IntelliJ, you will no doubt have seen what I call “right-click refactor” options.

Any of these automatic refactors are pretty much safe to do anytime without any worry of changing functionality.  These kinds of automated refactors simply apply an algorithm to the code to produce the desired result and in almost all cases do not change functionality.

These refactoring tools you can trust because there is not a chance for human error.

Any time you have the option of using an automatic refactoring, do it!  It just makes sense, even if you have unit tests.  I am always surprised when I pair up with someone and they are manually doing refactorings like “extract method” or “rename.”

Most of the time everything you want to do to some code can be found in one of the automatic refactoring menus.

Small step refactors

While not as safe as automatic refactors, if you have a refactor that is a very small step, there is a much higher chance your brain can understand it and prevent any side effects.

A good example of this would be my post on refactoring the removal of conditions.

The general idea is that if you can make very simple small steps that are so trivial that there is almost no chance of mistake, then you can end up making a big refactor as the net effect of those little changes.

This one is a judgment call.  It is up to you to decide if what you are doing is a small step or not. 

I do find that if I want to do a refactor that isn’t a small step refactor, I can usually break it down into a series of small steps that I can feel pretty confident in.  (Most of the time these will be automated refactors anyway.)

Turning methods into classes

I hate huge classes.  Many times everyone is afraid to take stuff out of a huge class, because it is likely to break and it would take years to write unit tests for that class.

One simple step, which greatly improves the architecture and lets you eventually create unit tests, is to take a big ol’ chunk of that class, move it to a new class, and keep all the logic in there exactly how it is.

It’s not always totally clean, you might have to pass in some dependencies to the new method or new class constructor, but if you can do it, it can be an easy and safe refactor that will allow you to write unit tests for the new class.

Obviously this one is slightly more dangerous than the other two I have mentioned before, but it also is one that has a huge “bang for your buck.”

Unit tests, or test code themselves

Another obvious one.  Unless you are going to write meta-unit tests, you are going to have to live a little dangerously on this one.  You really have no choice.

I think everyone will agree that refactoring unit tests is important though.   So, how come no one is afraid to refactor unit tests?

I only include this example to make the point that you shouldn’t be so scared to refactor code without having unit tests.  You probably do it pretty frequently with your unit tests.

I’m not advocating recklessness here

I know some of you are freaking out right now.

Be assured, my message is not to haphazardly refactor code without unit tests.  My message is simply to use temperance when considering a refactor.

Don’t forgo a refactor just because you are following a hard and fast rule that you need unit tests first.

Instead, I am suggesting that some refactorings are so trivial and safe that if it comes between the choice of leaving the code as it is because unit testing will take too long, or refactoring the code without the safety net, don’t be a… umm… pu… wimp.  Use your brain!

Things that will bite you hard

There are a few things to watch out for, even with the automatic refactorings.  Even those can fail and cause all kinds of problems for you.

Most of these issues won’t exist in your code base unless you are doing some crazy funky stuff.

• If you’re using dynamic in C#, or some kind of PInvoke, unsafe (pointer manipulation) or COM interop, all bets are off on things like rename.
• Reflection.  Watch out for this one.  This can really kick you in the gonads.  If you are using reflection, changing a method name or a type could cause a failure that is only going to be seen at runtime.
• Code generation.  Watch out for this one also.  If generated code is depending on a particular implementation of some functionality in your system, refactoring tools won’t have any idea.
• External published interfaces.  This goes without saying, but it is so important that I will mention it here.  Watch out for other people using your published APIs.  Whether you have unit tests or not, refactoring published APIs can cause you a whole bunch of nightmares.

This list isn’t to scare you off from refactoring, but if you know any of the things in this list are in your code base, check before you do the refactor.  Make sure that the code you are refactoring won’t be affected by these kinds of things.

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.

(See John MacIntyre’s post here if you are interested, and Uncle Bob’s response here.)

Well, as Forest Gump would say,  “Maybe it’s both.”

How can it be both?

I think overall writing clean code saves you money to build software.  (Unless the time you are going to spend maintaining the software is minimal or non-existent.)

The reason why it saves you money is where the both part comes into play.

If we just extracted the money part from the practice of writing clean code, we can make a pretty solid argument that overall it saves money by looking at what costs the most time and money in software development.

Go ahead take a guess.  What do you think it is?

That’s right.  Fixing a production bug. It may take awhile to write unit tests.  It may take awhile to refactor you code to be “clean.” But, if spending an extra 3 hours on a 3 hour coding task ends up saving you just 1 production issue, you’ve made your time back and then some.

The actual time expense of a production issue, all the way down the line, from project managers to QA to programmers to back to QA and back to deployment can easily cost 10 or more hours per issue, easily.

It’s really hard to argue against that logic by itself, but there is another element that comes into play here.

The human element.

You see it’s not all about dollars and money and what makes logical or practical sense when you throw humans into the mix.  I believe if the non-human benefits writing clean code didn’t save you any money, overall it would still save you money.

Let me explain.

No one takes pride in crap

I don’t care if the software works or if it looks pretty on the outside.  The person maintaining that code is going to have a different view of it.

If the internal code is crap, if it is nothing to feel good about, if it is a big pile of spaghetti code, it is going to severely demotivate developers.

And what do demotivated developers do?

All kinds of horrible things.  They look for new jobs.  They write more crap code.  They waste time and stall.  They do what they have to to get by until they can either get the heck out of this stupid profession, or that dream job comes along where they can write ASP.NET MVC code using an auto-mocking container and BDD.

Sometimes you have to ask yourself, is it really that much more difficult to maintain that existing VB6 app than if it were converted to C#?  Seems like it shouldn’t be, right?  It definitely is easier to maintain a nicely built C# application, but there is a compelling reason why those applications eventually get rewritten, even though they really might not need to.

Developers working on old crusty applications just are not motivated to do so.  Developers like new shiny technology.  They like to feel like they are learning and expanding their skills, not just maintaining status quo.

So even though rewriting that VB6 application doesn’t really make practical sense… even though your metrics and charts tell you that you shouldn’t do it…  When you do rewrite that application you will find this magical hidden cost savings, because suddenly developers won’t drag their feet trying to fix a bug or add a feature to “that crappy old VB6 app.”  To the customer that application might even look exactly the same, but to the developers working on it, it will be a brand new shiny toy.

Writing clean code is about more than saving money

So you see, in the theoretical there are argument about whether refactoring that code will actually be a positive return on investment or negative.  I’ll argue for the positive on purely practical and chartable theory every time, but when you throw in the human art element, it is no contest.

If your code  base is something that your developers take pride in, you will see huge savings in time, because your developers will be significantly motivated to make it even better.

Clean code begets clean code.

So when I say it is both, I’m not just being non-committal or luke-warm about the topic.  The human element makes that fact that clean code is art important to saving money.

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.

Take a moment to rest on your laurels before I tear your laurels to shreds.

Go ahead, I’ll wait.

Okay, now let’s get down to business.

Saying the same thing a different way

The problem with changing if-else statements into a switch statement is that nothing really has changed besides the dialect in which it was said.

It’s all apples!

Now, switch is slightly better than if-else for maintenance purposes, but not much better.  Both constructs (switch and if-else) try to represent some form of data (a mapping) as code.

Now data and code are not clearly delineated.  But, in general we have a concept of what constitutes data and what constitutes code.

Data is some information that does not contain in itself logic.

Code is some information that is primarily instructions and logic.

For this reason, I say that switch statements and if-else statements are both trying to treat data as logic.  They are both code constructs that mix in data elements with logic elements and do not clearly separate the two, although a switch statement does a slightly better job of it.

Consider the most basic form of an if-else and switch statement.  The form in which you directly map one piece of data to another piece of data.

If “A” then return “kittens”, If “B” then return “puppies”…

Switch (data1), case “A”: return “kittens”, case “B”: return “puppies”…

When I rewrite it in this form, the parallel becomes much more clear.   We can also very easily separate logic from data.

Data:

• ”A”
• ”B”
• ”kittens”
• ”puppies”

Logic:

• Map something of dataset1 to something of dataset2.
• Return a mapped value.

The problem with either of these forms, (the switch or the if-else), is that both of them tend to mix logic and data together.

Why is it bad to mix logic and data?

Let me ask you a question.  Which is more likely to change?

Hopefully it is data and not logic.

Consider the Single Responsibility Principle (SRP.)

A module should have one and only one reason to change.  Ideally, we want to separate out logic from data so that we can change the two independently.

Sticking with our contrived example, suppose we wanted to make “A” map to “dinosaurs” instead of “kittens,” or we want to add more mappings.  We should be able to do this in a way that does not interfere with the logic at all or add new logic.

If we have an if-else structure, we will have to add more if-else constructs or change a data value that is inside of the method that is doing the logic.  The same applies for a switch statement.  We are not declaring our data one place and our logic another, they will be side by side, right next to each other in the code.

Suppose we want to change the logic so that instead of returning a value, we assign it to some variable, or reverse it.  Again, we are faced with changing logic in multiple places, in the same module as the data.

Consider the case where we want to read the data from a file or some other data source?  Is that possible with a switch or if-else structure?  Not really, because the data is essentially “hard-coded” into the logic.

What can we do about it?

So by now hopefully you have gotten the point that your refactoring of the if-else into a switch statement didn’t really solve the basic problem of mixing data and logic together.

But now, you have another problem.  You need to separate your data and logic so that they can change independently.  You want to be a good steward of the SRP.  You want to someday be able to read your data from a file or database, so that you won’t even have to recompile your code to change it.

On my next post, I will show you how to take switch statements and refactor them into a better form that separates data from logic.

I will talk about the different “forms” of the switch statement and why to choose a particular method of refactoring over another.

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.

What surprised me is how much more clean a try catch solution seems to work than my original solution.

The unclean code

public void Process()
{
    foreach (string line in file)
    {
        string[] columns = line.split(',');
        foreach (string column in columns)
        {
            if (hasBadData(column))
            {
                LogErrorMessage();
                return;
            }

            Print(column);
        }
    }
}

I am using a short example here, so the refactoring might not really jump out to you as necessary, but let’s refactor it to be as clean as possible anyway.  (This comes from a much larger example where the refactoring is a must.)

Refactor 1: Returning booleans

public void Process()
{
    foreach (string line in file)
    {
        if (!ProcessLine(line))
        {
            return;
        }
    }
}

private bool ProcessLine(string line)
{
    string[] columns = line.split(',');
    foreach (string column in columns)
    {
        if (!ProcessColumn(column))
        {
            return false;
        }
    }
    return true;
}

private bool ProcessColumn(string column)
{
    if (hasBadData(column))
    {
        LogErrorMessage();
        return false;
    }

    Print(column);
    return true;
}

We’ve broken each loop into its own method and separated the handling of each line and each column in each line into its own method.  A good refactor that makes things a little more clear.

Notice the bool return types on the new methods and the special handling to return early if a result is false.  Most people when refactoring the first example (myself included) forget that the first example breaks out of both loops with an early return.

If you don’t take this into account, your behavior will be different.  When you refactor, your behavior had better not be different.

This is the crux of the problem.  Returning bools is bad.  It doesn’t make sense that our methods return bool.  What does the bool mean?  We happen to know it means success or failure, but will the next reader?  It seems very out of place, and look at the verbosity to handle the return types.

Refactor 2: Storing error state

This next refactor was what this post was going to be titled.  I was going to suggest in this post that you should not return boolean error states, but instead use the error state as part of your class.  I still think this is a decent solution.

private bool IsFatalError { get; set; };

public void Process()
{
    foreach (string line in file)
    {
        ProcessLine(line);
        if (this.IsFatalError)
        {
            return;
        }
    }
}

private void ProcessLine(string line)
{
    string[] columns = line.split(',');
    foreach (string column in columns)
    {
        ProcessColumn(column);
        if (this.IsFatalError)
        {
            return;
        }
    }
}

private void ProcessColumn(string column)
{
    if (hasBadData(column))
    {
        LogErrorMessage();
        this.IsFatalError = true;
        return;
    }

    Print(column);
}

What we have done here is stored some state information about our object instead of chaining result codes down the method calls.  This is a huge improvement, because our meaning is much more explicit and our object is holding its own state.

It still is quite verbose.  Why do we have to check for a fatal error everywhere?  Seems like we are likely to forget.

Still, much better than returning booleans.  If you are in a class don’t be afraid to manipulate the state of that class internally.  Many times you can eliminate return values and parameters passed into private methods in a class by simply making that data part of the class.

So, the verbosity was still bothering me.  So, I tried this:

Refactor 3: Exception handler flow control

public void Process()
{
    try
    {
        foreach (string line in file)
        {
            ProcessLine(line);
        }
    }
    catch (BadColumnDataException exception)
    {
        LogErrorMessage();
    }
}

private void ProcessLine(string line)
{
    string[] columns = line.split(',');
    foreach (string column in columns)
    {
        ProcessColumn(column);
    }
}

private void ProcessColumn(string column)
{
    if (hasBadData(column))
    {
        throw new BadColumnDataException();
    }

    Print(column);
}

This is surprisingly clean.  Notice that we don’t actually have to put if conditions in the loops to check whether or not we should return early?  Instead, if an exception is thrown, flow will jump immediately to the catch block where we will log the error message.

I’m a little bit uncomfortable to be using exception handling as a flow control mechanism, but given that:

1. When encountering the error, we are aborting the normal flow of the program completely (breaking out of two loops).
2. It is so much more clean and clear.

I think this is actually my preferred solution.  I normally would never use exceptions where I could reasonably detect the failure condition, but I may have to rethink that viewpoint.

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.

Now, I’m going to detail some of the techniques I have used to eliminate helper classes in legacy code.

First, let’s set a ground rule: We are not going to just jump into legacy code and eliminate helper classes for the heck of it.  Why?

1. It doesn’t have a good return on investment (ROI) for the time you spend doing it.
2. Your manager or general overlord will probably look at you with a disapproving frown, since you’re not adding any tangible value to the product.
3. If you break something, you will give refactoring a bad name, and be shunned by other developers.  You will have to wear a big red scarlet “R”.
4. It is not exactly fun.  I mean, it shouldn’t be fun…  Let me put it this way.  If this kind of thing is fun for you, then I’ve got a bunch of  other “fun” stuff you can do around my house.

So what are we going to do then?  We are going to refactor the helper class into real classes or existing classes when we are modifying or adding functionality to it.  Let’s get started…

Modifying a method

If you have to modify a method that is in a helper class, the very first step is to move the logic as it is into a concrete class that we can write a unit test for.  Here is an example:

public static int getDependantCount(MonsterObject stuff)
{
    int dependantCount = 0;
    List<Relation> relations = stuff.getPerson().getRelations();
    foreach(Relation relation in relations)
    {
        if(RelationshipHelper.isDependant(stuff.getPerson(), relation))
        {
            dependantCount++;
        }
    }

    return dependantCount;
}

Looking at this example, the first thing we need to do is to figure out what real class this helper class’s method belongs to.  (Quick side note here:  notice the helper method in question also uses another help class.  This is likely to be the case in the real world.)

One technique I use to figure this out is to look and see what data this helper method is using.  In this simple example it is pretty obvious that the data it is operating on belongs to Person, even though the method is passing in MonsterObject. Usually the correct place to move a helper method is the place where you will maximize the amount of this operators that are used in the method.

In this case, let’s move the helper method to person.  Here is what it would look like after:

private int getDependantCount()
{
    int dependantCount = 0;
    List<Relation> relations = this.getRelations();
    foreach(Relation relation in relations)
    {
        if(RelationshipHelper.isDependant(this, relation))
        {
            dependantCount++;
        }
    }

    return dependantCount;
}

Notice what we did here?

• We eliminated a parameter being passed in.
• We replaced a bunch of calls with this dot.
• We made the method non-static and private.
• And of course we moved it onto person, where it belonged.

We still have a reference to the helper method it was originally calling, but we can eliminate that later down the road.  If this logic ends up being complex, we might have a DependantCounter class that takes in a list of relations that our Person method instantiates and calls in order to get the person count.

Our next step here is to write a unit test that tests the current functionality, then check in our code.  Finally, after we have that done, we can write a unit test that will fail for the changes we want to make to the method, and then modify the method.

It is much cleaner and easier to do things this way, and we have just eliminated a method in a helper class!

Adding a method

Adding a method to a helper class is much easier.  JUST DON’T DO IT!!!  Instead figure out what data that method is going to operate on and move it to the class that contains that data.

If the functionality you are going to add is large and seems to have its own responsibility, then go ahead and create a new class.

As you are modifying code and bringing the helper methods into real classes, or adding new methods in classes that would have been in helper classes by convention, you may start to see some of the classes these methods are being moved into grow.   That is ok, you are discovering that you need more classes.  A helper class is not a spill over class for long methods that you don’t want to put into the class they actually belong in.  Instead, the appropriate thing to do is to break up the class based on responsibility.

To stick with the current example, imagine a Person class that has some data on it for money.  Perhaps there is a private variable called cashOnHand.  As you add to the class you may end up bringing in data on their savings account, their outstanding loans.  You might bring in methods that operate on their savings account information and their cash on hand.  It is ok, and good to discover that Person becomes a separate thing than a person’s financial data.  At that point you might create a class called Financials and a person would have a reference to it.

Refactoring helper classes is about figuring out where things belong.

It is just like cleaning out the junk drawer in your kitchen.  You have to go through each item and find out where its real home should be.  If there isn’t one, you might have to make one.

If a method operates on a piece of data, it belongs as close to that data as possible.  Don’t try and tackle the huge helper class all at once, but rather eliminate the helper class piece by piece as you change or add functionality.

Good question.  I don’t really know.  Neither does the helper class.

When you ask the helper class, what do you do… He half smiles, looks down at his over-sized feet and replies with a squirrely ”stuff”.

How to identify helper classes

There are a few common attributes we can look at that will tell us if we are dealing with a helper class, in no particular order:

• Doesn’t have a clear responsibility of any kind.
• Doesn’t hold any of its own state data.
• Has mostly or all static methods.
• Class name ends in helper.  (This is a good tip off!)
• If it does get newed up somewhere, it gets passed all around afterwards.
• Lives in a package or namespace called “utilities”.

A helper class is a class that contains auxiliary methods for other classes, but isn’t really a thing in and of itself.  A helper class is the opposite of object oriented programming. I wrote about the dangers of static methods before, and helper classes usually are the result of proliferation and breeding of static methods.

We are going to skip going any further into why they are bad and go straight into the burning question…  When you see one of these in your code base…

Should you just leave it there?

(The above picture means “No”)

When you see a car accident on the freeway that no one has reported, should you just drive on and not dial 911?

When you see an old woman being beaten on the street, should you walk right on by?

When you open your fridge, and you open the vegetable drawer and you see a rotting cucumber mush in a bag, do you just forget you ever saw it?

I’m not suggesting you should start diving into your legacy code base and start removing all the helper methods right now.  But what I am saying is that if you are working inside of a helper method to change some functionality and you think it is ok to just add one more method, using some lame excuse like “it’s the convention”, I’d like to take a big boat paddle and teach you some single responsibility.  Don’t be part of the problem.  Be part of the solution.

Here are some lame excuses for leaving helper classes and propagating them.

• I am just making a small change to the code.
• I don’t want to break this stuff that is already working.
• I am just following the convention of the architecture.
• I don’t understand how it works.
• There is no class this functionality belongs too.
• I’m a lazy bastard and I don’t care about making the world a better place.
• The world is going to end in 2012 anyway.

If you’re using one of these lame excuses… STOP IT!  3000 line helper classes weren’t born overnight.  Some idiot first created the class, then more idiots added methods to it.  Don’t be just another idiot.  I implore you.  We have enough.

John, I want to do the right thing… help me.

What?  You do?  I’ll assume you are being sincere… even though I have my reservations.

First take this oath.  Place your hand on The Art of Computer Programming and repeat after me.

I, <your name>, solemnly swear to not propagate the aberration or pure evil and generally sucky code known as the helper class.

I promise to uphold the values of single responsibility, data abstraction, and the open closed principle.

I will vanquish helper classes, and helper methods and properly put them in associated classes where they belong, under no less penalty than having my arms and legs removed with a butter knife.

Welcome initiates, next post I’ll tell you some techniques I use to eliminate helper classes.

Working with legacy code can be challenging.  Especially legacy code that was written by someone who didn’t know what they were doing and then modified 10 times by someone who didn’t care what they were doing.  (This is perhaps 90% of legacy code.)

I was having the tendency to jump right in and start implementing my clean feature in my own class that I would integrate into the legacy code, and move the relevant logic into my own class.

The good way

Let me see if I can summarize what my steps have looked like:

1. Create failing unit test for new functionality I am implementing.
2. Create new class which only has the logic for that functionality, but that I know overlaps some of the legacy code.
3. Repeat until my functionality is working.
4. Integrate the use of my class into the legacy code.
5. Start moving parts of the legacy code that share the responsibility of my class into my class.
6. Refactor the remaining legacy code.

The better way

I don’t think these steps are that bad.  But there is one problem, which is easily solved by adding the step of “Refactor the legacy code” at the beginning.  The problem is that of clearly knowing the responsibilities of the legacy code.  Most of the time in this situation the legacy code has multiple responsibilities.  When you are done implementing the new functionality and cleaning up the code, you should end up with several classes in single responsibility (SRP).

The problem is that poorly written legacy code tends to hide all of the things it is doing.  Refactoring the code first allows you to be able to understand better what responsibilities may be hiding in the code.  It also allows you to better see the true structure of the logic, which helps to clearly identify the class you want to pull out to put your new logic in.

So, a better set of steps for adding functionality to legacy code is:

1. Refactor legacy code to be as clean as possible.
2. Create failing unit test for new functionality I am implementing.
3. Create new class which only has the logic for that functionality, but that I know overlaps some of the legacy code.
4. Repeat until my functionality is working.
5. Integrate the use of my class into the legacy code.
6. Start moving parts of the legacy code that share the responsibility of my class into my class.
7. Refactor the remaining legacy code.

Function-Pointer, Enumeration, Map

When I get to combine 2 or more of these things together, I am usually pretty excited!  Map + Function Pointer to me is like a kick in the face to code duplication!

Why is this little combo so awesome?

Let me give you a little code example:

public void HandleData(DataPackage package)
{
    string packageType = package.GetType();
    switch(packageType)
    {
        case "RoundHouseKick":
            Player.RoundHouseKick(package.destination);
            break;

        case "FaceSlap":
            Player.FaceSlap(package.destination);
            break;

        case "EvilEye":
            Player.Taunt(package.destination);
            break;

        case "Bite":
            Player.Bite(package.destination);
            break;

        case "FireBall":
            Player.Fireball(package.destination);
            break;
    }
}

Rewriting this as a super-awesome-hard-to-contain-myself map of function pointers you get:

private Dictionary<string, Func<Destination>> moveMap = new Dictionary<string, Func<Destination>>()
{
   { "RoundHouseKick", Player.RoundHouseKick },
   { "FaceSlap", Player.FaceSlap },
   { "EvilEye", Player.Taunt },
   { "Bite", Player.Bite },
   { "FireBall", Player.FireBall },
};

public void HandleData2(DataPackage package)
{
   string packageType = package.GetType();
   moveMap[packageType](package.destination);
}

Now if we forgo the use of strings, but use an enumeration from the get go…  We achieve the most-super-awesome-ultimate-combo MAP OF ENUMERATIONS TO FUNCTION POINTERS!!!

public enum Moves
{
    RoundHouseKick,
    FaceSlap,
    EvilEye,
    Bite,
    FireBall
}

private Dictionary<Moves, Func<Destination>> moveMap = new Dictionary<Moves, Func<Destination>>()
{
    { Moves.RoundHouseKick, Player.RoundHouseKick },
    { Moves.FaceSlap, Player.FaceSlap },
    { Moves.EvilEye, Player.Taunt },
    { Moves.Bite, Player.Bite },
    { Moves.FireBall, Player.FireBall },
};

public void HandleData2(DataPackage package)
{
    Moves moveType = package.GetType();
    moveMap[moveType](package.destination);
}

Why is this so super awesome?

It isn’t as apparent in a little code snippet, but imagine an application where you have many sections of code that deal with this logic in the same way.  Often you encounter a third-party API that has methods or properties that are named after the type of data they work on or retrieve instead of having a parameter passed in.  In situations like these, it is very useful to map the mapping between data and logic into one location.

I also don’t like switch statements very much.  They can be confusing with the break statements in there, and end up being duplicated all over of the code base.  Anytime you see a switch statement in code, it is a possible candidate for the super-fantastic-mega-awesome-30-hit-combo of Map + Function pointer.