Should Helper/Utility Classes be abstract?

Question

I commonly find myself extracting common behavior out of classes into helper/utility classes that contain nothing but a set of static methods. I\'ve often wondered if I sho

Answer 1

By declaring them as abstract, you are in effect indicating to other coders that you intended for these classes to be derived from. Really, you're right, that there's not much difference, but the semantics here are really more about the interpretation of other people who look at your code.

Answer 2

Helper / Utility methods are just fine. Don't worry about adding them to a library inside your application or Framework. Most frameworks that I have seen use them in many varieties.

That being said, if you want to get really crafty about them you should look into extension methods in C# 3.0. Using extension method will make your Utilities a little more of a "holistic" part of your framework which it seems like what you're trying to do by considering to make them abstract. Not to mention extension method are a lot of fun to write!

Answer 3

I would add more step beyond the private constructor:

public class Foo {
   // non-instantiable class
   private Foo() { throw new AssertionError(); }
}

Throwing the AssertionError prevents methods in the same class from instantiating the class (well, they can try). This isn't normally a problem but in a team environment you never know what someone will do.

As regards the "abstract" keyword, I have noticed utilities classes subclassed in numerous instances:

public class CoreUtils { ... }
public class WebUtils extends CoreUtils { ... }

public class Foo { ... WebUtils.someMethodInCoreUtils() ... }

I believe this is done so that people don't have to remember which utility class to include. Are there any downsides to this? Is this an anti-pattern?

Regards, LES

Answer 4

I think it's better to declare utility classes final with a private no-args constructor. Moreover all members of this class should be static.

An easy way to do all this in one statement is to use the @UtilityClass annotation of Lombok:

@UtilityClass
public class Utilities{

   public String getSomeData() {
       return "someData";
   }

   public void doSomethingToObject(Object arg0) {
   }
}

If you use the @UtilityClass annotation you can skip the static keywords as in the example above since Lombok adds them automatically during compilation.

Answer 5

As others stated, make a private parameter-less constructor. No-one can create an instance of it, apart from the class itself.

As others have shown how it is done with other languages, here comes how you do it in the next C++ version, how to make a class non-instantiable:

struct Utility { 
    static void doSomething() { /* ... */ } 
    Utility() = delete; 
};