Fluent Interfaces: What am I missing?

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?

Published by

David Starr

David Starr is a professional software craftsman committed to improving agility, collaboration, and technical excellence in software development teams. David is the Technical Training Director for GoDaddy. He is the founder of Elegant Code Solutions, has served in numerous leadership contexts, and was as an early and consistent advocate for agile software development.

15 thoughts on “Fluent Interfaces: What am I missing?”

  1. 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.

Comments are closed.