zoukankan      html  css  js  c++  java
  • 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. 

  • 相关阅读:
    excel打印预览后整个表格中按页显示虚线,打印时就会打印很多页
    4.8 自定义下拉菜单模式Spinner与setDropDownViewResource
    1.2Matlab基本语法和基本操作.
    CTime类的一个BUG
    【转载】PE_Info 之DIY
    ubuntu使用记录
    反VM测试成功
    获取MAC地址
    【转载】秒到oep,支持所有壳,包括vmp
    【转载】Make your owner PE Protector
  • 原文地址:https://www.cnblogs.com/chucklu/p/13033056.html
Copyright © 2011-2022 走看看