java - 您是否应该为 Java 枚举定义一个空值/未知值？

Question

当您为接口(interface)中可能“未定义”的事物定义枚举时，您是否应该

• 为此定义一个单独的枚举值，或者
• 在这些情况下只使用 enumValue = null 吗？

例如，

serviceX.setPrice(Price priceEnum)

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN
}

和 priceEnum.UNKNOWN 在需要时

或

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE
}

需要时 priceEnum = null？

对此进行了一些辩论。想到的几点:

• 使用 Price.UNKNOWN 可以节省一些“if (price == null)”代码。您可以在单个 switch-case 中处理 Price x 的所有值
• 根据 View 技术，本地化 Price.UNKNOWN 可能更容易
• 使用 Price.UNKNOWN 会导致代码中出现“魔数(Magic Number)”问题，IMO。这里我们有 Price.UNKNOWN，其他地方可能有 Color.UNDEFINED、Height.NULLVALUE 等
• 使用 priceValue = null 与 Java 中其他数据类型的处理方式更加一致。对于未知值，我们也有 Integer i = null、DomainObject x = null、String s = null，不是吗？
• Price.UNKNOWN 强制您决定是否在所有用例中普遍允许空值。我们可能有方法 Price getPrice() 可能返回 Price.UNKNOWN 和 setPrice(Price p) 不允许接受 Price.UNKNOWN。由于 Price.UNKNOWN 总是包含在枚举值中，因此这些接口(interface)看起来有点不干净。我知道 priceValue = null 也有同样的问题(你不能在界面中定义 null 是否被接受)但感觉更干净一些，误导性更小(？)

Answer 1

这实际上是一个应用 Null Object pattern 的例子.恕我直言，拥有一个虚拟对象而不是空对象总是更好。例如，您可以向空对象添加虚拟方法，而不是将代码分散在各处进行空检查。很方便。

enum 的名称也为您提供了一些额外的语义:价格是 unknown，undefined，而不是 trustworthy，还不知道？如果价格为 null 是什么意思？

更新:正如 Aaron Digulla 指出的，空对象模式需要内存。但实际上大多数时候情况并非如此。在传统的实现中，您通常会在任何地方使用 Null 对象的单例，因为不需要单独的实例。使用枚举会变得更好，因为您可以免费获得单例语义。

另一点是 null 引用和对某个对象的引用占用相同数量的内存(比如 32 位机器上的 4 个字节)。正是被引用的对象占用了一些额外的内存。但如果这是一个单例，这里几乎没有内存开销。