1 Fluent Interfaces {anchor:Fluent Interfaces} Martin Fowler has an interesting article on what he calls {link:Fluent Interfaces|http://martinfowler.com/bliki/FluentInterface.html} (FI). Basically, an FI is an interface which allows you to chain mutator calls without having to create temporary variables. This style is of API is very convenient to use and it allows the code structure to more accurately represent the underlying data/object structure. Hierarchical structures like XML DOM’s, GUI Controls, HTML, and nested business objects are all good candidates for this type of interface. Here’s a simple example: Instead of doing something this this: {code} Person p = new Person(); p.setName(“Bob”); Address a = new Address(); a.setCity(“Bobville”); a.setCountry(“Canada”); p.setAddress(a); function(p) {code} You could instead do something like this: {code} function(new Person() .setName(“Bob”) .setAddress(new Address() .setCity(“Bobville”) .setCountry(“Canada”))); {code} The second FI implementation reads much nicer as you don’t have any intermediate variables to deal with and the actual structure of the code mimics the structure of the data. It almost has an XML feel to it. The way you implement this sort of thing of course is to have your setters/mutators simply return ‘this’. Ex. Instead of: {code} public void setName(String name) { name_ = name; } {code} You would do: {code} public Person setName(String name) { name_ = name; return this; } {code} 1 Constructors An added bonus of FI’s is that you often no longer need to accept initial values in your constructors. Many values are often only in the constructor as a matter of convenience, but with FI’s, it is already convenient. Why would you want to remove initial values from your constructors? There are three reasons that I know of: 1. So that your classes can be JavaBeans. To be a JavaBean you need a no-argument constructor. 1. So that your client code is more resilient to change. Something like {code}new User().setFirstName("Kevin").setLastName("Greer"){code} is more resilient than {code}new User("Kevin", "Greer"){code} in the event that in the future I add a middle-name property to both the Person class and the Person constructor. 1. No need for multiple constructors or constructor explosions. In example #2 above you could reasonably argue that you could just add an extra constructor which included the middle-name but have still kept the old two-argument constructor. The problem with this is that as you add more and more properties in the future you end up with a lot of old constructor signatures to maintain. Even if you've never changed the class you might feel compelled to add multiple constructors in order to support each possible combination of possible initial values that a user might want to provide. 1 Problems in Java There is however a problem with implementing FI’s in Java and that problem is inheritance. Let's extend the example above: {code} class Employee extends Person { … Person setSalary(long salary) { salary_ = salary; return this; } } {code} And now let’s use it: {code} new Employee() .setName(“Bob”) .setSalary(60000); {code} But this doesn’t work! Why? Because setName() returns a regular Person, not an Employee and person doesn’t have the setSalary() method. As soon as you start adding Fluent methods in subclasses, your FI becomes broken. 1 Other Languages As I’ve shown above, FI’s don’t work in Java when you use inheritance because of Java’s static type checking. In languages which perform run-time checking instead, such as Ruby, Smalltalk, Io, etc., this isn’t a problem. However, many of these languages actually have better language-based solutions to the problem so that you don’t need to implement FI's at the API level. 1 Io {code} p := Person clone do ( setName “Bob” setSalary 60000 ) {code} 1 Ruby {code} p = Person.new do |m| m.setName("Bob") m.setSalary(60000) end {code} 1 Smalltalk Smalltalk has a very nice feature called “cascading message sends”. It lets you send multiple messages (make multiple method calls in Java terminology) to the same object without having to keep repeating the object. In Smalltalk the period (.) is like Java’s semi-colon (;) end-of-statement marker. This leaves the semi-colon symbol free for use in describing a new method call which is related to the current object but still separate from the previous method call. Ex. Instead of doing this: {code} obj call1. obj call2 … obj calln. {code} You could just do this: {code} obj call1; call2; … calln. {code} So if we rewrite our FI example in Smalltalk with cascading message sends we get this: {code} p := (Person new) setName “Bob” ; setSalary 60000 . {code} Smalltalk’s behaviour is more like English. 1 Improving Java It is unfortunate that Java chose to stick with C’s semicolon delimiters rather than adopting Smalltalk’s use of semicolons and periods. I guess that wasn’t the point of Java; if Java had wanted to do everything that Smalltalk did, it could have just been Smalltalk in the first place. An approach that would work for Java would be to add something like Io’s “do” command. Maybe it would look something like this: {code} p.{ setName(“Bob”); setSalary(60000); }; {code} The idea being to introduce an implicit ‘this’ within a set of braces. 1 Summary Fluent Interfaces make API usage much more convenient and natural but don’t work well with inheritance in Java. Other languages provide better support for FI’s; often doing so at the language level without requiring API designers to add any explicit support. 2006-01-20 13:37:22.78 2006-01-20 13:37:22.78 I don't think you mentioned that Smalltalk methods return self by default. Java returns nothing - I still remember having an empty feeling when I first learned Java. Java Languages would be much more fluid if the methods returned 'this' by default. 2006-01-21 14:07:53.099 2006-01-21 14:07:53.023 I recently implemented this very pattern in a web application, in which I wanted to represent the current state (in the sense of REST) in such a way that I could say {code} state.getNextPage().getRest() {code} to get the URL which represents "the next page of results". In order to permit construction of arbitrary, unknown future subclasses, I use the factory method. {code} // pseudo-code class StateWithPage implements State { public State getNextPage() { return createState(this.page + 1); } protected State createState(final int page) { return new StateWithPage(page); } } class StateWithPageAndColor extends StateWithPage { protected State createState(final int page) { return new StateWithPageAndColor(page, this.color); } } {code} Jonathan Feinberg Jonathan Feinberg Jonathan Feinberg 2006-02-22 16:10:38.172 2006-02-22 16:10:38.044