Fluent Interfaces: How Far Is Too Far?

Humor me a moment. I know I’ve promised a series on REST/HTTP/HTML that will likely drive everyone nuts, but I had a thought this morning that is probably more bizarre than many others I’ve had. I have really enjoyed building and using fluent interfaces for tools I’m using. I think they can make the code both more readable and maintainable, though the approach differs from more traditional approaches. I’ve recently been working on a fluent interface for creating Atom items and feeds using the System.ServiceModel.Syndication namespace, and that has been both frustrating and fun.

This morning, however, I had the thought of creating a fluent interface for one of the most simple of concepts used in .NET: collections. What’s wrong with collections you ask? Nothing really. But what if instead of reading collection.Add(item) you could read Add.the(item).to(collection)? Which is more readable? In the end, that’s similar to what I’m doing with the System.ServiceModel.Syndication bit, except that you don’t generally just add one or a few things to the collection in the syndication example. We could create something similar to add and remove events, all using a single static Add/Remove class with various, overloaded methods for the common identification operations.

Is this overkill? As JB mentioned to me over IM, it’s relative. For some, I’m sure you will think I’m nuts. Others may think I am on to something. I don’t think I would go and do it for no reason at all, but if I ended up with some crazy list creation or end-user-wants-to-read-my-code scenarios, I might consider something like that. What do you think?

Advertisements