没有值的java枚举与私有构造函数的实用程序类之间的区别

Question

对实用程序类来说,常见的做法是为它们提供一个私有构造函数:

public final class UtilClass {
    private UtilClass() {}

    ...
}

但不幸的是,有些工具不喜欢私有构造函数.他们可能会警告它在类中没有被调用,它没有被测试覆盖,块不包含注释等.

如果您这样做,很多警告就会消失:

public enum UtilClass {;
    ...
}

我的问题是:除了对未来开发人员的无休止的仇恨之外,没有值的枚举和Java中的私有构造函数的类之间有什么重要的区别？

请注意,我并不是说Java枚举与具有公共静态最终字段的类相比有什么优势？.我不是在决定一系列事物应该是一堆常量还是一个枚举,我决定将一堆函数放在无构造函数的类或无值的枚举中.

另请注意,我实际上并不想这样做.我只想知道权衡作为一般语言知识的一部分.

例如,使用枚举会使用无用的方法污染自动完成UtilClass.values().还有哪些缺点？上升空间？

Answer 1

使用enum的东西,实际上不是一个枚举是丑陋和混乱.我会说这是不足以做到这一点的理由.

"实用类"模式是完全合法的.如果你的工具不喜欢它,这就是工具的问题.

Answer 2

一个好处是,您绝对可以保证不会创建任何实例,即使是在课堂内也是如此.

缺点是这超出了枚举的通常意图.但是,我们已经为使用枚举实现的单例执行此操作.

Joshua Bloch关于这些单例的"Effective Java"中的这一点也适用于实用类:

...你得到一个铁定的保证,除了声明的常数之外不能有任何实例.JVM提供了这种保证,您可以依赖它.

免责声明:我没有使用过这种模式,也不建议支持或反对它.

Answer 3

实用程序类中的以下模式还提供了可以没有实例的铁定保证:

public abstract class Util {
    private Util() { throw new Error(); }
    ... // static methods
}

此外,您没有额外的无关静态方法,由枚举提供.

Answer 4

唯一的区别是你仍然可以在你的类中调用构造函数:

public final class UtilityClass {

    public static final UtilityClass Instance = new UtilityClass();

    private UtilityClass () {}

    public static int Foo (int a, int b) {
         return a+b;
    }

}

但既然你是那个类的设计者,打破你自己的代码合同是没有任何意义的.

一般来说,我读过的大多数软件设计书都反对使用静态方法.除非它们确实是实用方法:从某种意义上说它们永远不会要求任何国家.即便如此,实现Singleton模式只需要很少的努力,以便在时间到来时,您可以为其分配状态:

public final class UtilityClass {

    public static final UtilityClass Instance = new UtilityClass();

    private UtilityClass () {}

    public int Foo (int a, int b) {
         return a+b;
    }

}

并称之为UtilityClass.Instance.Foo(2,5);.稍后在编码过程中执行引入状态转换将更加困难.因此静态方法难以维护.

为什么情况下是有用的原因是,你可以在很多像图案使用它们策略,如果在一个场合这取决于什么应该做什么,...利用static方法,一是让这些方法少动因为Java不支持方法指针(有充分理由).因此,非静态方法更具动态性和实用性.

此外,一些安全研究人员认为,使用static修饰符分析代码更加困难,因为它们可以从任何地方访问,副作用更难以预测(例如在自动安全分析工具中):比如你有一个没有完全实现的类,然后你仍然可以分析字段以了解它可以访问哪些方法,从而分析可能的副作用(网络使用,文件IO,......).这可以生成应该验证的每个类别的可能危险列表.至少如果我理解我的一位研究员的博士论文是正确的.因此,非静态方法允许更多的修饰分析.

总结:Java是基于面向对象编程的原则构建的.这意味着," Ç小姑娘世界"用于由Ç ompiler,而" 我 nstance世界"由我 nterpreter /运行.我同意这两个词之间存在很多冲突.但是static在很多/某些情况下,方法是解决此类冲突的错误.