Helper design pattern - an antipattern?

[TimeBomb]

The helper design pattern, arguably the same as the utility design pattern, is a design pattern in where multiple methods are available for use by other objects. It's designed to be used with applications written using OOP. As many are surely aware, the helper design pattern is commonly used in object oriented applications and frameworks.

 

I've read numerous interesting articles about this design pattern lately. Primarily, the argument that the helper design pattern is an antipattern. Helpers' cohesiveness is not a worry - some are cohesive, some not as much. For example, a single "Helper" class that has a mess of methods is not as cohesive as having numerous helper classes wherein each is dedicated for use by one specific object.

 

A big problem with helpers is that, all too often, objects rely on them, thus reinforcing the bad habit of tight coupling. So, if an object directly calls a helper method, the issue becomes tight coupling.

 

But, if the object doesn't rely on the helper method, what is the big deal? The object returns data which is then run through a helper method. The object isn't tightly coupled with the helper. Everything is good, right? Well, it's better than the previous implementation, but, in my opinion, it still isn't anywhere near ideal.

 

Personally, I stray away from helper/util design patterns, singularities, and even static variables and objects. The challenge then becomes primarily maintaining cohesiveness across the application while implementing the necessary functionality to correctly 'replace' helpers/static objects/etc. If an application is designed well enough from the ground up, singularities, static variables and objects, and helper classes all become completely unnecessary.

 

Nick Malik blogs on MSDN.com about the evils of helper classes. I found both of his articles on this subject quite intriguing.

http://blogs.msdn.com/b/nickmalik/archive/2005/09/06/461404.aspx - First article, talks about the evils of the helper class.

http://blogs.msdn.com/b/nickmalik/archive/2005/09/07/462054.aspx - Second article, talks about how to effectively replace the helper class with a more acceptable implementation.

 

So, what is your opinion of the helper design pattern? Do you use it? Why or why not? Do you believe you could improve the design of your application by removing all implementations of the helper (and similar) design pattern?

[trq]

So, what is your opinion of the helper design pattern?

 

I have never heard of it and taking a quick look at the articles you linked to, he is referring to *helper classes*, not some *helper* design pattern.

 

I would say for the most part I agree with his comments though. Creating classes of static *helper* methods opens yourself up to tight coupling between your helper classes and your actual code base. Presenting this same functionality without the static methods could potentially maker this a little better if you use dependency injection to access your *helper* objects within other objects.

[jawef]

I call those utilities classes (see http://en.wikipedia.org/wiki/Utility_class ) and consider them as part of the core of what OOP is but , I agree with some points of the articles that you provided. Most OOP programmers have procedural background and that is not the problem if you work 12 hours a day with a strict OOP language, but with PHP it is a bit different. You must really understand why this class should be a utility class and not an object; otherwise you just curry functional programming in your logic.