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

【问题标题】：Difference between java enum with no values and utility class with private constructor没有值的 java 枚举和具有私有构造函数的实用程序类之间的区别
【发布时间】：2023-04-01 20:11:01
【问题描述】：

实用程序类的常见做法是give them a private constructor：

public final class UtilClass {
    private UtilClass() {}

    ...
}

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

如果你这样做，很多警告就会消失：

public enum UtilClass {;
    ...
}

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

请注意，我不是在问What's the advantage of a Java enum versus a class with public static final fields?。我不是在决定一个事物列表是应该是一堆常量还是一个枚举，而是在将一堆函数放在一个无构造函数的类中还是一个无值的枚举中。

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

例如，使用枚举会用UtilClass.values() 之类的无用方法污染自动完成功能。还有哪些其他缺点？优点？

【问题讨论】：

我看到的主要缺点是它令人困惑。开发人员希望枚举是一个枚举，并且有实例，而不是伪装成枚举的实用程序类。
我认为对未来开发者无休止的仇恨是避免此类事情的充分理由。感觉这是一种避免工具警告的解决方法。如果这种模式变得足够普遍，工具最终也会发出警告。
实际上，一个空的enum 应该比私有默认构造函数触发一个更严重的警告。
Enums 是 Java 的一个被低估的特性。他们拥有大多数人永远不会想到的各种uses，而且在我看来，大多数开发人员人为地限制他们的能力这一事实并不是你这样做的好理由。话虽如此，这不是我通常做的。
附带说明，我通常用throw new AssertionError() 填充空的构造函数。实例化实用程序类是果断地（？）错误的。

标签： java enums private-constructor

【解决方案1】：

一个好处是绝对保证不能创建任何实例，即使是在类内部也是如此。

一个缺点是这超出了枚举的通常意图。但是，我们已经对使用枚举实现的单例进行了此操作。

Joshua Bloch 的“Effective Java”中关于此类单例的这一点也适用于实用程序类：

...你得到一个铁定的保证，除了声明的常量之外不能有任何实例。 JVM 做了这个保证，你可以依赖它。

免责声明：我没有使用过这种模式，也不推荐或反对它。

【讨论】：

带有枚举的单例具有可序列化的巨大缺点，如果您有 2 个枚举选项（基于 cfg） - 您可能最终（已经发生！）有 2 个不同的单例。单例永远不应该被序列化，而是在使用时解析。
这似乎与 OP 的问题无关。也就是说，我不确定我是否理解允许对单例进行序列化所造成的伤害。来自 JLS：“序列化机制的特殊处理确保永远不会由于反序列化而创建重复实例。” IIUC，您可以在多个类加载器中加载类并反序列化 - 但是枚举方法并不比其他方法差。
尝试像这样enum FactoryImpl implements SuperDuperFactory{ FastFactory{...}, MemoryEfficientFactort{....} }. 现在您有两个可能的 SuperDuperFactory 实例，但您可以配置为一次使用一个。但是，如果您反序列化引用 SuperDuperFactory 的实例，您最终可能会得到 2 个活动工厂。如果工厂不可序列化，则 if 将是一个错误 NotSerializableException。当然，对工厂的字段引用应该是暂时的，但是会发生这样的错误，枚举有助于掩盖它们，因为如果工厂相同，则它们是不可见的
单例是一个只有一个实例的类。您似乎有两个实例。看起来您使用的是策略模式而不是单例模式。这似乎与 OP 的问题无关。
这里是我谈论的一个例子：pastebin.com/LDLyMikx ByteBufferFactory 的实例只有一个。可能有不同的impl。基于系统配置，但实际上会有一个单一的实现......除非有不同的类型可以被反序列化。请注意，枚举实际上是不公开可见的，因此没有其他方法可以获取不同的实例。

【解决方案2】：

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

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); 调用它。稍后在编码过程中执行 introduce state 转换会更加困难。 因此静态方法更难维护。

实例之所以有用是因为您可以在很多模式中使用它们，例如策略，如果在某个情况下它取决于应该做什么，...通过使用 static方法，一个使方法不那么动态，因为Java不支持方法指针（有充分的理由）。 因此非静态方法更加动态和有用。

此外，一些安全研究人员认为，使用 static 修饰符分析代码更加困难，因为它们可以从任何地方访问，并且副作用难以预测（例如在自动安全分析工具中）：假设您有一个类那还没有完全实现，那么您仍然可以分析字段以了解它可以访问哪些方法，从而分析可能的副作用（网络使用情况、文件 IO ......）。这可以生成应验证的每个类别的可能危害列表。至少如果我理解我的一位研究人员的博士论文是正确的。 因此非静态方法允许更多的修饰符分析。

总结：Java 是建立在面向对象编程的原则之上的。这意味着 c 编译器使用“class world”，i 使用“instance world” 解释器/运行时。我同意这两个词之间有很多冲突。但是static 方法在许多/某些情况下是解决此类冲突的错误。

【讨论】：

人类会犯错误。因此，即使破坏您自己的代码没有意义，它还是会发生。零错误风险比微小错误风险更可取，尤其是在您编写大量代码时。

【解决方案3】：

实用程序类中的以下模式还提供了不存在实例的铁定保证：

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

此外，您没有额外的不相关的静态方法，由枚举提供。

【讨论】：

是的，但是有多少人会阅读他们不应该调用该构造函数的规范？我认识的一些人浪费了几个小时才发现他们所做的事情违反了代码合同。我建议将构造函数设为私有。
对，但这不是问题所在。还有……铁定的？如果你没有标记类 final，你可以使用 finalizer (similar to this) 执行子复活。
《钢铁侠》有点强。反序列化可以创建一个实例，即使使用这个构造函数。并且可以添加额外的构造函数。
@AndyThomas：好点子，如果有人破解了 java 字节码，就可以导出“类代码”并让反序列化器完成工作。虽然，正如一些人 (@Jimmy) 所说，static 方法并不是给程序员的真正礼物。
@Strilanc：那是C#，而不是Java。 Java 从未允许循环构造函数，即使您操纵字节码以拥有这样的类文件，复活也不会像 “An object o is not finalizable until its constructor has invoked the constructor for Object on o and that invocation has completed successfully (that is, without throwing an exception).” 那样工作。换句话说，没有super()，没有finalize，也就是说，这个黑客没有机会......

【解决方案4】：

将enum 用于实际上不是枚举的东西是丑陋且令人困惑的。我会说这是足够的理由不这样做。

“实用程序类”模式是完全合法的。如果您的工具不喜欢它，那是工具的问题。

【讨论】：