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. 

  • 相关阅读:
    居然就这么没有了
    RAID4 in WAFL
    网络存储导论第15章:Netapp产品分析
    radwareAPSolute应用前端解决方案全局负载均衡解决方案
    RAID , LVM and EVMS
    FND_STANDARD.SET_WHO
    基于基表的Form开发
    eclipse pydev 升级地址
    .net程序员应该知道的
    收集利用Jquery取得iframe中元素
  • 原文地址:https://www.cnblogs.com/chucklu/p/13033056.html
Copyright © 2011-2022 走看看