Are Helper Classes Evil?

Lorenzo Barbieri @ UGIblogs! — Tue, 06 Sep 2005 17:51:58 GMT

re: Are Helper Classes Evil?

matt — Tue, 06 Sep 2005 17:58:36 GMT

Hmmm.... interesting. But I'm not sure that I agree with your definition.

So if I take a helper class and convert all static methods to instance methods, does that now make it less evil? I create all of my "helper classes" in such a way that they need to be instatiated and passed references to the particular instance of the class that they are "helping". Would this still be considered evil by your standards?

re: Are Helper Classes Evil?

Jim Arnold — Tue, 06 Sep 2005 18:05:32 GMT

Nice to see someone from Microsoft making a stand against this anti-pattern! Now maybe you could have a word with some of your colleagues :-)

Jim

re: Are Helper Classes Evil?

Nate — Tue, 06 Sep 2005 18:07:26 GMT

This is all good and all, but if helper classes are undesireable, where do you put miscellaneous code that you would normally put in a helper class? Where does that method go that say, helps encode a URL? Or that function that converts an array to a comma delimited list? Or in C#, that wrapper for a certain Win32 API?

In all practicality, I find that I often have these piddely tasks that don't really lend themselves to encapsulation within an object and are pretty much on their own, but are called from myriad places.

If I was coding in C++, I would place it outside of a class, but languages like C# and VB.NET don't allow me to do that. Does it violate OO principles? Of course it does. But OO principles are not meant to be a straightjacket.

All that said, I do agree that if they show up in a UML diagram, your helper class is probably doing more than isolating a "piddely task" and that something is probably wrong.

re: Are Helper Classes Evil?

William Sullivan — Tue, 06 Sep 2005 19:23:23 GMT

I can think of one case where helper classes are useful... Code re-use in a company. For instance, a company has a policy on how its programs will access and write to the registry. You wouldn't want some products in the company saving its data in HKLM/Software/CompanyName/ProductName and some under .../Software/ProductName and some .../"Company Name"/"Product Name". So you create a "helper class" that has static functions for accessing data in the registry. It could be designed to be instantiatable and extendable, but what would be the advantage? Another class could implement the companies' policy on encryption, another for database access; each could be created in a similar way, under different namespaces in the same DLL. That package can then be used by each developer. I would agree that having a single catch-all for all of these functions would not be good OO, but this method would still violate some of the principles you outlined in your post...

re: Are Helper Classes Evil?

NickMalik — Wed, 07 Sep 2005 00:19:20 GMT

I'll try to answer more than one comment in this reply:
To Matt: would making the methods non-static... would that be less evil? Yes. You are no longer in violation of the Open-Closed Principle. Would the ability to pass the object to the classes that use it make it less evil? Yes: you are now using Dependency Injection. It is also a lot more testable.

To Nate: I appreciate your practicality. However, I don't agree that there are many cases where code is truly miscellaneous. Encoding a URL is part of a URL object. Converting an array to a comma-delimeted list is an extension of the array object itself. Wrappers for API calls are usually best when created as private methods inside the class that needs to call the API.

To William Sullivan: The largest reusable code base that all your developers are already using is the .Net Framework. The vast majority of the framework uses instantiated classes, not static helper classes (there are exceptions, unfortunately). So, the need for reuse is NOT a good argument for helper classes.

re: Are Helper Classes Evil?

Nate — Wed, 07 Sep 2005 17:27:09 GMT

I agree that ideally, URL encoding should be in a URL object and so on, but what about the practical scenario where objects like URL and array objects are provided by the framework, and one does not have the ability to modify the framework?

Take say the .NET array object; I want to use that object but I do not have the ability to add a method that does a custom parse job. Subclassing the array to simply aggregate behavior without modifying existing behavior strikes me as overkill.

I emphatically agree that 99% of the time, it probably isn't necessary to use a helper class, and that most of the time that are abused; but that does not detract from the other 1% of the time.

As for William Sullivan's argument, I'd like to hear how you would approach the specific scenario he proposed, as that is exactly the kind of scenario for which I find helper clases useful. I'm honestly curious.

re: Are Helper Classes Evil?

Nate — Wed, 07 Sep 2005 18:08:31 GMT

Just to add another example, say that you are writing .NET code to retrieve the string for a Win32 error message. This requires calling the Win32 API FormatMessage() and doing some non-trivial munging on the results to get the string into a .NET string.

This is best done in a helper class because there really isn't any object to instantiate per se, and it is non-trivial so you would not want to duplicate this code in every place that you would want to use it. Granted, you could write code that looked like this:

wec = new Win32ErrorCodeConverter();
string message = wec.Convert(errorCode);

...but this would result in an instance object that is no different than any other instance; a gross misuse of OOP.

Another good example of a helper class in .NET is the System.Convert class. The only other place I could imagine putting that functionality would be on the root Object class itself.