Just A Summary : Fluent Interfaces

Trackback from The Infotainment Telesector: Fluent Interfaces, aka Method Chaining on Fluent Interfaces

Thu, 29 Dec 2005 14:46:22 -0600

A few folks have been talking about “fluent interfaces”. I first saw this pattern (and it’s Smalltalk roots) described as “method chaining” in Hibernate In Action: Method chaining is a programming style supported by ma…..

Comment on Fluent Interfaces by Joe Reddy swcses.eponym.com

Wed, 10 Jan 2007 10:43:31 -0600

I like your 7 points. I too have been practicing the idea of “fluent” interfaces for awhile without giving it a name. Although I don’t use Visual Basic much anymore, the English-like syntax was very attractive.

I espcially ike the “Just Principle” I think I will use that when explaining using an english-like appraoch to interfaces.

Take care,

Joe http://swcses.eponym.com

Comment on Fluent Interfaces by Bob

Thu, 15 Mar 2007 12:04:03 -0500

The fluent interface has been around for more than 20 years most likely from SmallTalk. This was considered cool in the early 1990s and fell out of favor for the same reasons that a complicated single line for loop with only a semi-colon body is now avoided.

From: j...@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: ********
Message-ID: <6590264@hplsla.HP.COM>
Date: 26 Sep 89 18:54:01 GMT
References: <3863@helios.ee.lbl.gov>
Organization: HP Lake Stevens, WA

In any case, assignment to this is considered obsolete with 2.0, though
still allowed for backward compatibility.  Expect C++ compilers to not
support assignment to this in the future.  Not allowing assignment to
this can allow more efficient compilers. For example, consider the following
oop style of chaining commands:

---------------------------------------------------------------------------
class something
{
public:
 something& dothis();
 something& dothat();
 something& doanotherthing();
};

something& something::dothis(){ /* do something, then */ return *this;}
something& something::dothat(){ /* do something, then */ return *this;}
something& something::doanotherthing(){ /* do something, then */ return *this;}

main()
{
  something I;

  I.dothis().dothat().doanotherthing();
}

Comment on Fluent Interfaces by Piers Cawley

Thu, 15 Mar 2007 12:36:26 -0500

I can’t honestly say I’m advocating doing that. Even in Smalltalk where a method defaults to returning self unless you tell it to return something else, you’d use a cascade:

SomeClass new
  doThis;
  doThat;
  doTheOther

is rather neater than:

|anObject|

anObject := SomeClass new.
anObject doThis.
anObject doThat.
anObject doTheOther

Interestingly, the Rails framework now defines a returning method which can be abused to give something like Smalltalk cascades:

returning(SomeClass.new) do |o|
  o.do_this
  o.do_that
  o.do_the_other
end

but it does seem rather clumsy next to Smalltalk’s syntax.

Comment on Fluent Interfaces by Bob

Thu, 15 Mar 2007 14:24:15 -0500

This C++ practice of chaining together member function calls fell out of favor because writing the code using traditional means was about the same number of lines of code without hiding the implementation details. It also fell out of favor because it promotes writing code that does not do error handling for individual member functions called (via a large try/catch block around all of the calls).

Code like the following should be avoided by having an AddLineItem(string, quantity) method for BillingRecord

BillingRecord r = new BillingRecord()
LineItem i = new LineItem("Apples", 10)
r.AddLineItem(i)
LineItem j = new LineItem("Pears", 10)
r.AddLineItem(j)
LineItem k = new LineItem("Oranges", 10)
r.AddLineItem(k)

Comment on Fluent Interfaces by Piers Cawley

Thu, 15 Mar 2007 15:32:36 -0500

While I take your point, your comments seem to be directed more at Martin Fowler’s original post than this one.

You seem to think that exposing implementation details is a good thing, which strikes me as odd; I’ve always taken the view that you leave the implementation to the object and concern yourself with coming up with message protocols that are relevant to the task you want the object to perform.

Comment on Fluent Interfaces by dan ros

Sat, 18 Aug 2007 03:46:27 -0500

good once

Comment on Fluent Interfaces by Stehan Schmidt

Sun, 30 Sep 2007 03:09:46 -0500

The blog and the comments mix different concepts. They miss the point. This reminds me of David Weinbergs “There is no problem.” The blog post mainly talks about DSLs and the comments about cascading calls. upTo and belongsTo are not examples for fluent interfaces. Fluent interfaces are more than this. They are semantically on a higher level. Fluent interfaces use clever cascading calls with clever return types to create human readable constraint or object descriptions.

Quaere is an example of an fluent interface.

http://andersnoras.com

Peace -stephan

— Stephan Schmidt :: stephan@reposita.org Reposita Open Source – Monitor your software development http://www.reposita.org Blog at http://stephan.reposita.org – No signal. No noise.

Comment on Fluent Interfaces by Piers Cawley

Sun, 30 Sep 2007 14:03:59 -0500

Looking at Quaere, I find it hard to think of any API that requires the user to pass ‘executable’ string arguments as being particularly fluent.

You seem to be under the impression that interface fluency is something that only applies to a particular domain, and in that, I think you’re flat out wrong.

Fluent interfaces can crop up anywhere. The (1 upTo: 10) do: [ ... ] example I gave from Smalltalk exhibits exactly what you claim is the distinguishing feature of a fluent interface. It’s an example of a cascading call that makes use of a clever return type (a message sent to a number builds a range object) to build a human readable loop.

Admittedly, it’s not as tiresomely clever as some fluent interfaces can be, but denying that it’s fluent simply because it doesn’t fit your model of where fluent interfaces should be used isn’t really on either.

I contend that fluency is a condition that all api designers should aspire to, whatever their domain. Smalltalk uses fluency to solve problems that other languages address by introducing syntax. Fluently designed classes like Range and the rest of the collection hierarchy, coupled with well thought out constructors on other classes mean that a Smalltalk image is well supplied with expressive, fluent ways of specifying loops and other types of control flow, that the language itself has special syntax for handling control flow.

Every time I come back from exploring smalltalk, I find myself wondering about adding ifTrue(&block), ifFalse(&block), ifNil(&block) etc to ruby…

So far, I’ve resisted.

Comment on Fluent Interfaces by Neil Martin

Wed, 05 Dec 2007 04:01:49 -0600

I have referenced this post in my post : http://neildmartin.spaces.live.com/blog/cns468.entry468.entry

I love method Chaining and fluency in its place it is very powerful and makes API’s easy to consume however it isnt the end of the story and can be used very badly i liked your 7 points.

Comment on Fluent Interfaces by Mert Nuhoglu

Sat, 17 May 2008 05:49:32 -0500

I think, Stephan Schmidt’s blog post on this topic is the way to go: Fluent Interface and Reflection for Object Building in Java