Fluent interfaces and leaky abstractions

Question

What is a fluent interface? I can't find a good definition of this, but all I get are long code examples in a language I am not very familiar with (e.g. C++).

Also, what is a leaky abstraction?

Thanks

Answer 1

A fluent interface a term Eric Evans coined and it's just another name for method chaining. Martin Fowler wrote a couple of articles on this subject, but it roughly looks like this:

m_Window = window::with()
 .width(l_Width)
 .height(l_Height)
 .title("default window")
 .left(200)
 .top(200)
.create();

Fluent interface are generally used to create named parameters in a language that doesn't support them (the Named Parameter Idiom in C++ for example), or in Domain Specific Languages to make the code read more fluently.

I've seen them being used for everything from image processing libraries, to regular expression libraries, 3D libraries. Other examples include the construction of tree structures, lists, or other datastructures. Everything that requires the construction of complex objects (load of parameters) can make use of Fluent Interfaces to make it more readable. For example, compare the previous example to the CreateWindow function call:

 ::CreateWindow(
      "Window class", 
      "Window title", 
      dwStyle, X, Y, 
      nWidth, nHeight, 
      hWndPant, hMenu, 
      hInstance, NULL
 );

Answer 2

Here's a regular every-day interface:

public interface NotFluent
{
  void DoA();
  void DoB();
  void DoC();
}

And here's a fluent interface:

public interface Fluent
{
  Fluent DoA();
  Fluent DoB();
  Fluent DoC();
}

The most obvious difference is that when we return a void, we return instead an instance of the interface type. What's understood is that the interface returned is the CURRENT INSTANCE, not a new instance of the same type. Of course, this isn't enforceable, and in the case of immutable objects (like string) it is a different instance but can be considered to be the same instance only updated.

Here are examples of their use:

NotFluent foo = new NotFluentImpl();
foo.DoA();
foo.DoB();
foo.DoC();

Fluent bar = new FluentImpl();
bar.DoA().DoB().DoC();

Notice that the fluent interface is easier to use when chaining different calls. IRL, check out the Linq extension methods and how each call is designed to flow into another. None of the methods return void, even if it would be a valid result.

Answer 3

In a fluent interface, a object's methods will return a reference to the object, so that you can chain the method calls together.

For example, in NValidate, I did this to simplify parameter validation:

public City GetCity(string zipCode)
{
   zipCode.Assert("zipCode").IsNotNullOrEmpty().HasLength(5,10).Matches("\\d[5]-\\d[4]");
   // Continue processing
}

I can't speak to leaky abstractions, though.

Answer 4

A fluent interface is an API that allows you to write code that reads more or less like normal English. For example:

Find.All.Questions(Where.IsAnswered == true);

Method-chaining is usually used as part of the implementation, but there is more to it than that. To quote Fowler:

I've also noticed a common misconception - many people seem to equate fluent interfaces with Method Chaining. Certainly chaining is a common technique to use with fluent interfaces, but true fluency is much more than that.

It is also often called an internal DSL, since the syntax resembles that of a DSL, but it is implemented inside the host language instead of being processed by a parser.

Answer 5

An object-oriented interface is fluent if methods that are executed for side effect return self, so that such methods can be chained together.

I first encountered fluent interfaces in 1990 when the Modula-3 Interface Police (I am not making this up) required all initialization methods to return the object initialized. I believe this usage predates the coinage of the term "fluent interface".

Answer 6

A leaky abstraction is an abstraction where the details of the underlying reality often "leaks through".

All abstractions lie more or less, but sometimes the abstractions is such a bad fit to the underlying reality, that is causes more harm than it helps.

A simple example of a "leak" in an abstraction might be the usual float type. It seems to represent general real numbers and you can use it to perform basic calculations. But at some time you encounter a scenario where 1/3*3 != 1 or 1 + 10^-20 = 1. That is when the actual implementation details leak through and the abstraction breaks.

Answer 7

Thanks guys.

Great description.

My thought about fluent interfaces where that they were for readability. I could always read a chain of methods and how one is related to the previous/next method.

E.g. like the poster who posted the validation example (I have written code similar to that before).

Answer 8

Neal Ford does a nice job of explaining and giving Fluent Interface examples in his book the 'Productive Programmer'.

Traditional Object or 'bean' with getters/setters:

Car car = new CarImpl();
MarketingDescription des = 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);

Meet the same need with a fluent interface:

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

Answer 9

You can find a good definitition and the basic concepts of the fluent interface this this post:

Guidelines to Fluent Interface design in C# part 1

I hope that helps.