Posted by: jsonmez | April 12, 2010

Should I Leave That Helper Class

The project I am working on is riddled with “helper” classes.  What is a helper class?

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.



  1. The helper helps everybody. It says so right in the name. Do you want to be the guy that hurts the helper? What kind of person are you. I bet your computer is fueled by the souls of orphans. You and your object oriented programming. Psh.

  2. […] to Refactor the Helper Class In my previous post, I posed the question Should I Leave that Helper Class?  Hopefully I’ve convinced you that you should not leave the helper […]

  3. […] about static methods here, and how bad they are.  I also talked about why you should get rid of helper methods and how to get rid of […]

  4. Great blog… I often think their should be some sort of post-work penalty for the “programmers” who do these things. I did a lot of contract programming in Java/J2EE projects and all but a few had helpers and tons of other “worst practices”. Its like the original programmers made little messes all over and then connected them all together. I’ve only seen a few managers budget for cleanup and those only a two week blitz. Alas, I’ve been guilty of making “helper” classes too. I figured we’d refactor them but we never did. Of course this was in a startup where I was producing over 50% of the code plus trying to run the business. My partners were happy to be part as long as I did all of the work. Still, that’s a lame excuse I know. Should have named them and designed them for what they were.

  5. […] 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. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: