Hey, that’s a really cool trick, returning a context specific object with clever names on it. Sometimes it even makes sense when I read it. More often than not, though, it doesn’t.

The problem is the developer who wrote the fluent interface is fluent in the underlying things being abstracted and the developer consuming the API isn’t. This is often why I am using an API, after all.

I don’t want to pick on any particular API, because I know that people who have written these things sweat over them and craft them and bleed into them. I am not saying your work sucks.

That said: Can someone help me understand what is fluent about this? To me, it just doesn’t read as we expect fluency to read. I get it because I have worked with the API for awhile, but that’s not the point is it? Isn’t the point of a fluent API to encourage discoverability?

With.Mocks( mocks ).Expecting( delegate
    // Record expectations
    Expect.Call( dependency.SomeMethod() ).Return( null );
    // Replay and validate interaction
    IComponent underTest = new ComponentImplementation( dependency );
    result = underTest.TestMethod();

How about this one? It reads a little better, but getting to this final composition takes a LONG time of understanding what each object along the way is meant to be and do.

var twitter = FluentTwitter.CreateRequest()

I am not saying there is no place for this style, but I do think our tools are a bit rough for this technique to be effective. As I try to discover the appropriate functionality within the API to accomplish what I am after, my Intellisense if clogged with all of the standard object cruft like .ToString().

This doesn’t help me find the right way to use the API and frankly I find this style to be extremely noisy. Is it just me?

Previous post

Call for Code Cast Feedback

Next post

How I Learn


  1. February 23, 2009 at 7:24 am

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

  2. March 2, 2009 at 12:53 pm

    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.

  3. March 3, 2009 at 8:10 am

    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.

  4. March 21, 2009 at 5:52 pm

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

  5. March 22, 2009 at 3:08 pm

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