Fluent Interfaces: What am I missing?

February 17th, 2009

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 );
})
.Verify(delegate
{
    // 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()
    .Configuration.CacheUntil(2.Seconds().FromNow())
    .Statuses().OnPublicTimeline()
    .AsJson();

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?

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

  • http://www.truewill.net/myblog/index.php Bill Sorensen

    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.

  • http://www.sidesofmarch.com Brian DeMarzo

    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.

  • Pingback: Progressive Interfaces | Elegant Code

  • http://blog.jordanterrell.com Jordan Terrell

    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