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?

David Starr Esoterica