Java 富枚举类型 : Specifying Constant-Specific Behavior With Function Objects vs. 常量特定方法

Question

在 Java 中，函数对象是无状态对象的实例(通常是实现策略接口(interface)的单例)，其方法对其他对象的状态进行操作。这些是将函数指针作为参数传递给方法的 Java 等效项，就像在 C 等语言中所做的那样。

1.5 中引入的 Java 枚举规范使程序员能够通过将策略“接口(interface)”指定为枚举声明中的一系列抽象方法声明来复制函数对象模式，然后必须为每个枚举常量实现这些声明。

因此，如果想将特定于常量的行为与枚举常量相关联，至少有两种选择:

• 您可以先声明Enum实现您的策略接口(interface)，然后将行为作为函数对象存储在最终的enum 实例字段。然后，客户端代码可以通过 enum 字段访问器方法调用该行为。

• 您可以在Enum 声明中将“策略”声明为一个或多个抽象 方法。编译器会坚持为每个 enum 常量实现这些。然后，客户端代码可以通过 enum 常量直接调用方法来调用行为。

在我看来，函数对象方法需要更多资源。需要在堆上分配对象，对于大型枚举，这可能是几十个对象。通过访问器调用的需要似乎需要更慢的执行速度，但我猜想现代 JVM 实现将足够智能以内联方法调用，从而使两种模式之间的执行速度相似。

我目前使用函数对象来为我编写的 JDBC 数据库应用程序指定“动态”元数据。这些对象描述了数据库的某些特性，例如列和行不变量、用于创建与枚举类对应的数据模型对象的工厂、用于获取和改变数据模型对象数据的访问器，以及其他类似的元数据。

这种方法确实需要大量的样板文件。很多样板文件。

虽然使用特定于常量的方法并不能保证消除样板文件，但这种方法应该更简洁、更易读……而且可能更有效。

我是否应该重构我的枚举设计以使用特定于常量的方法来代替函数对象？

Answer 1

Should I refactor my enum design to employ constant-specific methods in place of Function Objects?

如果您关心 enum 方法调用的性能和引用的额外成本(最多 10 纳秒)，您根本不应该在关键路径中使用数据库。一次数据库访问通常为 10,000,000 纳秒。即使是您已经拥有的查询的行访问也可能是 10,000 纳秒。 Java Chronicle 被设计为超轻量级、无 GC、无锁、低系统调用、数据持久化，甚至在 100 到 500 纳秒的数量级来持久化和重新读取一些更大的业务对象。

简而言之，您必须弄清楚什么规模对您很重要，然后首先开始优化最大的打击者。这意味着使用商业分析器分析您的应用程序，当分析器放弃并说您没有创建任何垃圾并且没有使用任何 CPU 或访问任何数据库时，只有到那时您才应该开始担心成本取消引用和使用对象来保存函数。