Utility classes should not have public constructors

Utility classes should not have public constructors

Utility classes, which are collections of static members, are not meant to be instantiated.

C# adds an implicit public constructor to every class which does not explicitly define at least one constructor. Hence, at least one protected constructor should be defined if you wish to subclass this utility class. Or the static keyword should be added to the class declaration to prevent subclassing.

Noncompliant Code Example

public class StringUtils // Noncompliant
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

Compliant Solution

public static class StringUtils
{
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

or

public class StringUtils
{
  protected StringUtils()
  {
  }
  public static string Concatenate(string s1, string s2)
  {
    return s1 + s2;
  }
}

 

Is it mandatory utility class should be final and private constructor?

 java版本的解释，不过java和C#不同，并没有top level的static

This is not a mandate from functional point of view or java complication or runtime. However, its coding standard accepted by wider community. Even lot of static code review tools like checkstyle and many others checks that such classes have this covention followed.

Why this convention is followed , is already explained in other answers and even OP covered that.

I like to explain it little further , mostly Utility classes have the methods/functions which are independent of object instance. Those are kind of aggregate functions.As they depend only on parameters for return values and not associated with class variables of utility class. So, mostly these functions/methods are kept static. As a result, Utility classes are ideally classes with all the static methods. So, any programmer calling these methods don't need to instantiate this class. However, some robo-coders (may be with less experience or interest) will tend to create object as they believe they need to before calling its method. To avoid that creating object, we have 3 options :-

1. Keep educating people don't instantiate it. (No sane person can keep doing it.)
2. Mark class as abstract :- Again now robo-coders will not create object. However, reviewes and wider java community will argue that marking abstract means you want someone to extend it. So, this is also not good option.
3. Private constructor :- Protected will again allow the child class to create object.

Now, again if someone wants to add new method for some functionality to these utility class , he don't need to extend it , he can add new method as each method is indepenent and no chance of breaking other functionalities. So, no need to override it. And also you are not going to instiantiate, so need to subclass it. Better to mark it final.

In summary , Creating object of utility classes does not make sense. Hence the constructors should either be private. And you never want to override it ,so mark it final. 

 

作者:Chuck Lu    GitHub