Comments on: Fluent Interfaces: What am I missing?

By: Jordan Terrell

Jordan Terrell — Sun, 22 Mar 2009 21:08:14 +0000

Check out the following to get rid of the “standard object cruft like .ToString()”:

http://www.clariusconsulting.net/blogs/kzu/archive/2008/03/10/58301.aspx

By: Progressive Interfaces | Elegant Code

Progressive Interfaces | Elegant Code — Sat, 21 Mar 2009 23:52:18 +0000

[...] wrote this post about a month ago where he challenged the usefulness of fluent interfaces. One of his concerns is [...]

By: Brian DeMarzo

Brian DeMarzo — Tue, 03 Mar 2009 14:10:17 +0000

I’ve got to agree, most fluent interfaces don’t feel terribly fluent to me, ESPECIALLY those which use simple English words as methods — the Is() And() Not() Or(), as Steve Bohlen mentioned.

Consider two hypotheticals:

Assert.IsTrue(someVal, “Should be true”);

Assert.That(someVal).Is(true).Otherwise(“Should be true”);

When I read code, I want to read CODE, not English words with horrible character delimiting.

By: Bill Sorensen

Bill Sorensen — Mon, 02 Mar 2009 18:53:25 +0000

Personally I find Moq ( http://code.google.com/p/moq/ ) much more intuitive than Rhino Mocks. Substituting lambdas for anonymous delegates might improve readability, too.

By: Dew Drop - February 23, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop - February 23, 2009 | Alvin Ashcraft's Morning Dew — Mon, 23 Feb 2009 13:24:41 +0000

[...] Fluent Interfaces: What Am I Missing? (David Starr) [...]

By: Sergio Pereira

Sergio Pereira — Sun, 22 Feb 2009 22:00:11 +0000

Nobody wanted to say this, but I will. Fluent Interfaces look goofy and stupid in C#. I’m never confident where to find the building blocks of the API (are they methods of the returned objcet, are they arguments?). I keep saying that we will be embarrassed by the amount of energy we are putting in these monstrosities a few years from now. I also agree with everything Steve commented above.

By: Colin Jack

Colin Jack — Fri, 20 Feb 2009 16:49:20 +0000

“FluentNHibernate and the Windsor Registration syntax are arguably much better than their XML alternatives in many regards, but even if they had been coded in non-fluent-interface-style this same would be true of them IMHO”

I agree, I also find discoverability to be a missing part of the puzzle. I haven’t explored this space massively but I like fluent interfaces to be very discoverable, I want them to lead me in the right direction and I find most don’t, they produce readable results but only but working out how to get the fluent interface to do what I want isn’t any easier than with a normal interface in a lot of cases right now.

By: Steve Bohlen

Steve Bohlen — Fri, 20 Feb 2009 11:53:29 +0000

I’ve blogged about this in the past and got walloped over the head for it but I’ll try one more time here: many of these interfaces are NOT fluent, they are LEGIBLE.

FLUENT implies that its easy to SAY something which (when intellisense is your only composition tool) is rarely the case with many of these. I don’t want to see verbs in my intellisense list, I want to see methods named something like the action I’m trying to achieve in my code. When I see .Is().Not()….. code, a little bit of the professional inside of me dies

It may very well be that once written these interfaces are indeed more LEGIBLE than otherwise, but calling them fluent as though they make it easier to SAY what you mean is a red-herring for all but the best of these approaches. Things like FluentNHibernate and the Windsor Registration syntax are arguably much better than their XML alternatives in many regards, but even if they had been coded in non-fluent-interface-style this same would be true of them IMHO.

By: Adam Tybor

Adam Tybor — Thu, 19 Feb 2009 15:49:06 +0000

Fluent interfaces can certainly be abused and overused as we are seeing that happen now. The good news is fluent interfaces help us create systems based more on convention and readability which in the end will help with maintenance.

Fluent NHibernate and Windsor Registration are two that really come to mind. No more xml hell and I can dot through the configuration with intellisense and the code becomes intention revealing. Very nice!

As for the two examples above they are abusive, but thats still a good thing. We need to test the limits before we know what works and what doesn’t.

By: Robin Robinson

Robin Robinson — Thu, 19 Feb 2009 13:36:54 +0000

@BrianGenisio

I would take it a step further and using something like this:

Assert.True(contidition.IsEqualTo(5))

I use these types of extensions in some of out internal framework code because:

if(result.IsEqualTo(expected))

looks better than

if(result == expected)