What is a helper? Is it a design pattern? Is it an algorithm? [closed]

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.

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; }
    }
}

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.