By 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 rotting cucumber mush in a bag, do you just forget you ever saw it?

rotting cucumber which represents a helper class

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 to.
  • 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, in my next post I'll tell you some techniques I use to eliminate helper classes.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."