Java Rich Enum Types: Specifying Constant-Specific Behavior With Function Objects vs. Constant Specific Methods

Question

In Java, Function Objects are instances of stateless objects (typically singletons that implement a strategy interface) whose methods operate on the state of other objects. These are the Java equivalent of passing function pointers as arguments to method as one would do in languages such as C.

The Java Enum specification introduced in 1.5 enables programmers to replicate the Function Object pattern by specifying the strategy "interface" as a series of abstract method declarations in the enum declaration which must then be implemented for each enum constant.

Therefore, if one wants to associate a constant-specific behavior with an enum constant, there are at least two choices:

• you can have the Enum declaration first implement your strategy interface and then store the behavior as a Function Object in a final enum instance field. The client code could then invoke the behavior through an enum field accessor method.

• you can declare the "strategy" as one or more abstract methods in the Enum declaration. The compiler would insist that these be implemented for each enum constant. The client code could then invoke the behavior by calling the method directly through the enum constant.

It seems to me that the Function Object approach would require more resources. Objects would need to be allocated on the heap and for a large enum this could be a few score of objects. The need to invoke through accessors may seem to require a slower execution, however I would guess that modern JVM implementations would be smart enough to in-line the method invocations, thus making the execution speed similar between the two patterns.

I currently use Function Objects for the purpose of specifying "dynamic" metadata for a JDBC database app that I've written. These objects describe certain features of the database such as the column and row invariants, the factory to use to create a data model object corresponding to the enum class, accessors to get and mutate data model object data, and other similar metadata.

This approach does require a lot of boilerplate. A lot of boilerplate.

While using constant-specific methods does not promise to eliminate the boilerplate, this approach ought to be more concise and readable ... and perhaps more efficient.

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

Answer 1

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

If you care about the performance of an enum method call and the extra cost of referencing (up to 10 nano-seconds) you shouldn't be using a database in your critical path at all. A database access is typically, 10,000,000 nano-seconds. Even a row access for a query you already have can be 10,000 nano-seconds. Java Chronicle is design to be ultra-light weight, GC less, lock-less, low system call, data persistence and even it is in the order of 100 to 500 nano-seconds to persist and re-read some larger business objects.

In short, you have to work out what scale matters to you and start optimising away the biggest hitters first. This means profiling your application with a commercial profiler and when the profiler have given up and says you are not creating any garbage and not using any CPU or hitting any database, only then should you start worrying about the cost of dereferencing and using objects to hold functions.