You have a class X, you have a class called XHelper. XHelper contains methods that make it easy to use X.
The problem I have with this antipattern is that XHelper does nothing of value. If the methods are truly related to X then they should actual be class methods of X. However if you need “helper” methods to use the API of X chances are what is really required is a refactoring of X to incorporate the enhancements of XHelper invisibly. You shouldn’t need a helper to use an API.
Take Rails page helpers. A helper to construct the content of a page contains functionality that would be better marshalled in the controller, prior to view rendering. If multiple controllers perform the action then extract it to a service that controllers can invoke on the requests and delegates they are co-ordinating.
What if the Helper class actually refactors common functionality from classes X and Y and is actually called FooHelper because it helps perform Foo in X and Y?
Well, here we are onto something, we have some common functionality which is good and the name of the class reflects its purpose. The same question arises though, could FooHelper’s methods actually reside in Foo? If Foo is purely a function or method call then perhaps all the functionality relating to Foo should be encapsulated in a Foo class that presents the foo method.
Alternatively perhaps there is a better name than “Helper”? As examples, I tend to call collections of class methods that transform instances of one class into instances of another class “Transformers”. Similarly methods that create database connection instances could be called “Providers”. If you cannot make the class a private class instance of the class or classes the Helper is nominally a Helper to, then there is usually a better name for the class lurking around somewhere.
One thought on “The Helper Anti-Pattern”
I answer to this post, even 3 years later, because on google this page was my first result when I entered ‘java helper anti pattern’.
I saw so many Helpers that shouldn’t exist in my work… I came to the conclusion that the helper issue comes from Java. In Java, if you want to add a method to the class String, because it should belong to String, you can’t because it’s some class from the kernel objects and you can’t modify anything from the kernel. So basically, you would need to add a method to String, but you can’t, you cannot either add an extension to the class because java doesn’t support it. So what can you do ? Well, the only way is to create a StringHelper.
I used to developed in Smalltalk where helpers are considered as a beginner mistake done by people who don’t really understand what is an object. But, recently, some people from java came to the smalltalk world because they like the debugger, the browser… And now, we can see this kind of helpers things in Smalltalk too ! Well, you can tell a java developer that has a 10 years experience doing helpers not to do it, but it’s too late for this kind of guys…
Perhaps a better name, instead of helper, could be great. But look at the Math class in java, what is this thing ? And the name is very good to describe this thing that java developers call an object.
Usually if you are not in a java-like language, you could replace the FooHelper by methods in Foo (directly in the Class (ex : Smalltalk) or through a class extension (ex : Objective-C)) or by a FooProxy (some people say FooManager instead of FooProxy). But there might be other cases I missed.
Thank for this great article.