Been reading about fluent interfaces recently and I think it’s a really great way of making your code more readable. For those unfamiliar with the term, a fluent interface is basically a watered down DSL where you write chained method calls in a form resembling sentences, which makes the code more readable.

In an example taken from The Productive Programmer, a team is building an app dealing with train cars and each train car had a marketing description. Train cars have lots of rules and regulations
associated with them, so they had to ask their business analysts if they had the perfectly nuanced definition of the type of car they needed to test. The version they showed the analysts initially was:

Car car = new CarImpl();
MarketingDescription desc = new MarketingDescriptionImpl();
desc.setType("Box");
desc.setSubType("Insulated");
desc.setAttribute("length", "50.5");
desc.setAttribute("ladder", "yes");
desc.setAttribute("lining type", "cork");
car.setDescription(desc);

While this looks perfectly normal to a Java developer, their business analysts couldn’t grasp it and hated it. Since translation of business requirements into code inevitably increases the chances of errors in the understanding of requirements, the team rewrote the above code in the form of a fluent interface to mitigate the problem. The fluent interface looks like this:

Car car = Car.describedAs()
             .box()
             .length(50.5)
             .type(Type.INSULATED)
             .includes(Equipment.LADDER)
             .lining(Lining.CORK);

As it turns out, the business analysts liked this much better. Most of the boilerplate code required by Java convention was removed, and the implementation was simple. All the mutators returned this instead of void, allowing the team to create sentences by chaining the method calls together. The implementation of Car looked like the following:

public class Car {
      private MarketingDescription _desc;
      public Car() {
          _desc = new MarketingDescriptionImpl();
      }
      public static Car describedAs() {
          return new Car();
      }
      public Car box() {
          _desc.setType("box");
          return this;
      }
      public Car length(double length) {
          _desc.setLength(length);
          return this;
      }
      public Car type(Type type) {
          _desc.setType(type);
          return this;
      }
      public Car includes(Equipment equip) {
          _desc.setAttribute("equipment", equip.toString());
          return this;
      }
      public Car lining(Lining lining) {
          _desc.setLining(lining);
          return this;
      }
  }

Beautiful, isn’t it? Of course, by doing this, your POJO will no longer conform to the JavaBeans spec, which makes fluent interfaces iffy to use on classes that will interact with frameworks that rely on the class conforming to the spec.

Nevertheless, fluent interfaces are still a very viable coding style that can be used for internal classes that deal with heavily with business logic. It’s especially useful when your code will have to be paraded in front of non-technical analysts to ensure that the business requirements have been translated accurately to code. Sometimes, showing raw code to the people with the business knowledge is much better than writing reams and reams of functional specs and hours and hours of showcasing the UI.