What is a helper? Is it a design pattern? Is it an algorithm?

Question

Maybe a little tongue-in-cheek, but as I can't find this answer anywhere through Google, so to ensure Software Engineering has the answer:

What is a helper?

I have seen the name being used everywhere (module names, class names, method names), as if the semantics were deep and meaningful, but in the context of Computer Science (although I don't have a degree in it), I've never seen a description or definition anywhere!

Is it a design pattern? Is it an algorithm? I once worked on a program in which the module and class were both called somethingsomethinghelper (where somethingsomething was fairly generic too) and I promptly renamed it to something that made sense to me, but I feel like I'm missing something here!

Answer 1

A Helper class is a lesser known code smell where a coder has identified some miscellaneous, commonly used operations and attempted to make them reusable by lumping them together in an unnatural grouping. Successive developers have then come onto the project and not realised that the helper class exists, and have consequently rewritten the same common operations, or even created more Helper classes.

But seriously, the main problem with Helper classes is that they are usually operations that act on a specific class, which obviously means in OO terms that they are suffering from an acute case of Feature Envy. This failure to package the behaviour with the data it acts on is why developers so often (in my experience) fail to find it.

In addition to this, as you have already identified SomethingSomethingHelper is actually a terrible name. It is undescriptive, and gives you no real inkling of what sort of operations the class does (it helps?), which also means that it's not obvious when adding new behaviours whether they belong in the Helper class or not. I would break up such classes along the lines of related behaviour that logically group together, and then rename the new classes to reflect what it does.

Answer 2

A helper is a harmless additional class or method, as long as it complements an external component. When it does the contrary, then it indicates bad design because the code has been excluded from its authority, if there is any authority at all.

Here is an example of a harmless helper, I use a method called FindRep that counts the number of leading zeros.

digits = digits.Remove(0, TextHelper.FindRep('0', digits, 0, digits.Length - 2));

The helper method is very simple, but very inconvenient to copy-paste around and the framework does not provide any solution.

public static int FindRep(char chr, string str, int beginPos, int endPos)
{
    int pos;

    for (pos = beginPos; pos <= endPos; pos++)
    {
        if (str[pos] != chr)
        {
            break;
        }
    }

    return pos - beginPos;
}

And here is an example of a bad helper:

public static class DutchZipcodeHelper
{
    public static bool Validate(string s)
    {
        return Regex.IsMatch(s, @"^[1-9][0-9]{3}[A-Z]{2}$", RegexOptions.IgnoreCase);
    }
}

public class DutchZipcode
{
    private string value;

    public DutchZipcode(string value)
    {
        if (!DutchZipcodeHelper.Validate(value))
        {
            throw new ArgumentException();
        }

        this.value = value;
    }

    public string Value
    {
        get { return value; }
    }
}

Answer 3

A helper is ...

I'd say there are 3 significant traits of a helper: useful, compact, independent. A helper is something (usually a function) that works across the project and does one small thing. We can live without them but it would be painful.

Example:

function linesOf($mls) {
    return preg_split('/\s*\n\s*/',trim($mls));
}

How to use:

$fruitList = linesOf('
apples
bananas
cherries


');
// now you have ["apples","bananas","cherries"]

Note: this example is PHP, but JS also has multiline strings now so it's just as good.

So what we have is,

• Useful: This tiny function can have a big impact on how you organize your code - you'll love to put your literal lists in multiline strings. It's their natural form, super editable, no quotes on data lines, no comma, no nothing. Try it, you'll never go back to JSON for small lists.

• Compact: Well, it's a glorified regex pattern; you could write it every time you need the functionality, we just made it more readable.

• Independent: It doesn't depend on other classes, it's lightweight, runs out of the box, you could drop it into any of your projects with a CtrlV and it would just work.

So that's what helpers are. Tiny tools for generic jobs; you can organize them into their own class for namespacing reasons, or you can collect all your string helpers into one, array helpers to another, but most of the time (depending on how frequently you'll be using them and how obvious their role is) you just leave them in the global space.

Thumb rule:
If it's super helpful but doesn't seem to belong anywhere, it's probably a helper.

Answer 4

Helper is a commonly used name appendage.

However, it communicates very little about what it does. Every time I have seen it used I have found it to be a suboptimal name.

In fact I consider it to be a code smell that indicates more problems underneath.

Example

Suppose we see the name "WidgetHelper" (here "widget" is a stand-in name for any sort of programmable functionality, and not necessarily a UI widget):

class WidgetHelper:
    ...

What do we learn from the name? We know the object or function does some kind of work secondary to the widget. It is my experience that this might not even actually be true, and one might delete "helper" from the name and improve the communication.

For another possibility, "WidgetHelper" could be wrapping the widget, such that the widget code itself may know nothing about the helper. The implication is that WidgetHelper in this pseudocode example is part of the public API:

class WidgetHelper:
    def __init__(self):
        self.widget = Widget()
        ...

In this case, something like "WidgetAPI" would be a better name, because that, at least, informs the user its relationship to the Widget class. Or perhaps we delete "Helper" from the name and additionally rename Widget to something like WidgetImplementation.

Alternatively, it could be wrapped and called by the widget, implying it is not part of the public API, but rather part of the implementation details.

class Widget:
    def __init__(self):
        self.widget_helper = WidgetHelper()
        ...

Even in this case, with this small amount of information we have an improvement on "helper." It would be more descriptive to call it some generic name like "WidgetImplementation."

"Implementation" may be correct as the implementation may do too much to give it a more precise name. Or it may itself be too vague - this is at the discretion of the namer.

But as we have seen, the name, "helper," doesn't aid in understanding what is going on in the code, other than it is ancillary to the main object of interest. "Helper," could mean many kinds of relationships. Thus, it is overly vague and nebulous, and not well-suited for the purpose of informing the user what the object does.

Conclusion

Naming things is one of the hard problems in computer science.

What is desirable in a name is that it inform the user what the named thing is supposed to do.

But in any case imaginable, it would be more descriptive to use a name other than "helper" or simply remove it altogether.

As a corollary to my experience and this discussion, the choice of "helper" in a name also signals low effort or sophistication on the part of the namer (correctly or not). It is, indeed, a code smell.

Please don't call anything a "helper."

Answer 5

Of course "this is a gray area," but my pragmatic experience has been that people invent "helpers" when they have identified some useful-to-them set of common code that they don't want to re-implement. (Some languages refer to these as "mixins.")

The problem is that the common-code is tangentally related to each of the other classes that it might "help." Instead of being some part of a strict class hierarchy, it merely "helps" [all of ...] them. This strategy avoids duplication of source-code but it is not without its dangers.

Answer 6

Short answer

A code OR data OR code with data that helps to complete particular operation/computation.

Answer 7

My company used to use the Base class / Helper class methodology where each object would have two classes. You would have a Person class that contained all of the class properties and definitions and a PersonHelper class that contained all of the methods, SQL statements and Logic that manipulated the Person class. This worked well for us because all of our applications use SQL statements to manipulate data and it was very easy for us to find and modify the SQL statements as needed.

We have since moved on and now put everything in the Person / Base class. We quit using the Helper naming convention because we wanted to have less files in our projects. Also, the length of some of the class names were getting out of control. lol.

Not a great example but you get the idea.

s = CompanyName.PersonHelper.GetPerson()
s = CompanyName.Person.GetPerson()

I'm not saying that using the helper naming convention is the perfect solution but it did work for us for a few years.