Creating a fluent interface for Google Collections

Chris wrote about functional programming in Java. As an example he used Google Collections which “is a suite of new collections and collection-related goodness for Java 5.0”.

Looking at his post he gives the following code on how to use Goolge Collections

This is very verbose and hard to read. Mostly due to the static method calls and the seperation of the first “filter” and the “new PagesToFilesTransformation()” parameter. Using a static import we can reduce this to:

Better. I’ll show you how to make this even more readable with a fluent interface. I use the following example for this:

We want to move this code to a fluent interface. Martin Fowler wrote about Fluent Interfaces on his bliki and there is a entry on Wikipedia. They were made popular by JMock as a way to specify mock expectations.

What is a fluent interface though? For me it’s an interface to an API which is more consistent and readable. Which helps you do several steps with an API in a correct way. It’s often implemented with speaking method names and call chaining. These together create the illusion of natural, descriptive language. When the chained methods return the correct type, most often it’s impossible to call the wrong methods or methods in the wrong sequence. Therefor fluent interfaces create better readable code with less bugs. Which distinguishes them from domain specific languages (like in Ruby on Rails), macro programming (Lisp) or plain language constructs (methods which take closures) like “[1..5].each { … }”. The differences is fluent ;-) “5.times.each {…}” could be considered a simple fluent interface.

The most recent fluent interface in Java with some fame is Quaere, a kind of LINQ for Java for querying object graphs. There even is a promising Quaere API for JPA. I really think fluent interfaces are useful, although others think they are stupid. I keep to myself what I think is stupid and we see where this all is going to.

Back to our example. I’ve recently shown how to create a fluent interface for object creation. One for Google Collections might look like this:

This example isn’t optimal, but much more readable than the one given by Chris. The or() part could be improved because it doesn’t look very nice. This will change with closures. Fluent interfaces will boom with closures in Java 7.

In the comment to his blog post, Chris mentions “Making a fluent interface to do this might be a little risky, because I think there’s an expectation* that a method like Iterable.filter() wouldn’t modify the source iterable itself, but rather would return a new, filtered iterable.” We do not need to modify the Iterable, we only hold a reference and create new fluent interfaces on the fly as needed. Our code to enable a fluent interface for Google Collections this is rather simple:

This example has several main points. The with() static method call is descriptive and creates a fluent interface object for us to hold the Iterable object. Second most methods in fluent interfaces return the object itself. We create a new fluent interface object in filter to wrap the filtered iterable and enable chaining. My last example with object creation did hold the same bean and did not create new objects on the fly. This really depends on what should be done. We could have set the new iterable instead of creating a new wrapper like this:

This mostly depends on your style and if you think immutable objects are good or bad. For this I prefer the immutable Fluent Interface object over the mutable. Perhaps this is a pattern.

Conculsion:: A fluent interface for Google Collections would be useful. It’s more readable, less error prone and flows. Although my example works and is usable, there needs to go more work into a fluent interface for Google Collections to make it useful. For example support more Predicates and support transformations.

Thanks for listening.

Fluent Interface and Reflection for Object Building in Java

A post by Randy Patterson on creating fluent interfaces in C# got me thinking. Randy shows how to create a Fluent Interface to build an object. He uses a Person class (POJO) with setFirstName and a PersonFluentInterface class with firstName. Creating an object and setting some attributes needs quite a lot of code:

The alternative and the usual way is to use a constructor and set the attributes. Often this results in unreadable constructor calls when creating objects (no paramter names in Java):

What is “Frank”, “Pat” and especially “true” ? In Groovy and other languages we could write:

Indeed this is one of the best Groovy features and can be utilized when writing unit tests for Java classes. With a fluent interface the PersonFluentInterface class, which calls the setters on the POJO for him, Randy can write something similiar:

The set method in Person returns the PersonFluentInterface wrapped around the Person class. This looks more readable than calling lots of setters on an object and more readable than a large constructor call. We can do even a little better than Randy. With an additional method call we can combine the two lines in his example into one:

Randys approach requires the developer to implement a PersonFluentInterface class which calls the correct setters on the object. The only thing we would need is the interface description of the Fluent Interface to enable the IDE to support code completion and provide static checking.

I thought about a class which then maps the interface to a POJO with reflection. Some minutes later I was done. Voila!

Together with the interface we can now extend our Person POJO with an additional static method and we’re ready to use a fluent interface to create our POJOs.

Some future ideas: when using byte code instrumentation instead of a proxy we could use a abstract class which extends Person and calls the setter on itself. This would allow us the drop the create() call and add custom builder methods like “isMemberOfGroup(group)”.

I’m quite satisfied with the results. Some lines could be tweaked and optimized, but overall the solution works. I’m going to use this for some time to decide if it’s worth writing and maintaining the additional interface. But most probably it will increase the readability of large constructor calls for others and for me – after I haven’t read the code in question for some weeks.

Thanks for listening.

Update: There is a small bug in the examples ;-)