tags:

views:

466

answers:

6

How does one go about create an API that is fluent in nature?

Is this using extension methods primarily?

+8  A: 

This article explains it much better than I ever could.

EDIT, can't squeeze this in a comment...

there are two sides to interfaces, the implementation and the usage. There's more work to be done on the creation side, I agree with that , however the main benefits can be found on the usage side of things. Indeed, for me the main advantage of fluent interfaces is a more natural, easier to remember and use and why not, more aesthetically pleasing API. And just maybe, the effort of having to squeeze an API in a fluent form may lead to better thought out API?

As Martin Fowler says in the original article about fluent interfaces:

Probably the most important thing to notice about this style is that the intent is to do something along the lines of an internal DomainSpecificLanguage. Indeed this is why we chose the term 'fluent' to describe it, in many ways the two terms are synonyms. The API is primarily designed to be readable and to flow. The price of this fluency is more effort, both in thinking and in the API construction itself. The simple API of constructor, setter, and addition methods is much easier to write. Coming up with a nice fluent API requires a good bit of thought.

As in most cases API's are created once and used over and over again, the extra effort may be worth it.

And verbose? I'm all for verbosity if it serves the readability of a program.

fvu
I don't really understand how this makes for a fluent API, and actually think this design pattern is very verbose.
badbod99
ok... so it matches the wikipedia definition http://en.wikipedia.org/wiki/Fluent_interface I still think it's horrible to implement.
badbod99
Verbose doesn't serve the readability of the program in this case, it serves the readability of the client application. Your API still needs to be improved and maintained.
badbod99
Although I do agree, more thought put into an API design can't be a bad thing.
badbod99
Do you use LINQ? if so, that's an excellent example of a fluent API. Have fun without it!
RCIX
A: 

No and yes. The basics are a good interface or interfaces for the types that you want to behave fluently. Libraries with extension methods can extend this behavior and return the interface. Extension methods give others the possibility to extend your fluent API with more methods.

A good fluent design can be hard and takes a rather long trial and error period to totally finetune the basic building blocks. Just a fluent API for configuration or setup is not that hard.

Learning building a fluent API does one by looking at existing APIs. Compare the FluentNHibernate with the fluent .NET APIs or the ICriteria fluent interfaces. Many configuration APIs are also designed "fluently".

Abel
+2  A: 

KISS: Keep it simple stupid.

Fluent design is about one aesthetic design principle used throughout the API. Thou your methodology you use in your API can change slightly, but it is generally better to stay consistent.

Even though you may think 'everyone can use this API, because it uses all different types of methodology's'. The truth is the user would start feeling lost because your consistently changing the structure/data structure of the API to a new design principle or naming convention.

If you wish to change halfway through to a different design principle eg.. Converting from error codes to exception handling because some higher commanding power. It would be folly and would normally in tail lots of pain. It is better to stay the course and add functionality that your customers can use and sell than to get them to re-write and re-discover all their problems again.

Following from the above, you can see that there is more at work of writing a Fluent API than meet's the eye. There are psychological, and aesthetic choices to make before beginning to write one and even then the feeling,need, and desire to conform to customers demand's and stay consistent is the hardest of all.

Chad
+1  A: 

What is a fluent API

Wikipedia defines them here http://en.wikipedia.org/wiki/Fluent_interface

Why Not to use a fluent interface

I would suggest not implementing a traditional fluent interface, as it increases the amount of code you need to write, complicates your code and is just adding unnecessary boilerplate.

Another option, do nothing!

Don't implement anything. Don't provide "easy" constructors for setting properties and don't provide a clever interface to help your client. Allow the client to set the properties however they normally would. In .Net C# or VB this could be as simple as using object initializers.

Car myCar = new Car { Name = "Chevrolet Corvette", Color = Color.Yellow };

So you don't need to create any clever interface in your code, and this is very readable.

If you have very complex Sets of properties which must be set, or set in a certain order, then use a separate configuration object and pass it to the class via a separate property.

CarConfig conf = new CarConfig { Color = Color.Yellow, Fabric = Fabric.Leather };
Car myCar = new Car { Config = conf };
badbod99
The upsides of a fluent API (better readability and a much more intuitive way to work with your API) are much more important than to have a little bit more complicated code. IF you create an API, then it's all about the user that will access your API. If you can please him with a fluent style, I would take all the effort to make working with the API as easy as possible, even if that would mean putting a lot of more work into the API.
Sebastian P.R. Gingter
It creates a different interface than everyone else's interface. That doesn't help anyone understand your API or use it easily. The initializer or property object model is much more standard, and self describing in normal OO.
badbod99
+2  A: 

MrBlah,

Though you can write extension methods to write a fluent interface, a better approach is using the builder pattern. I'm in the same boat as you and I'm trying to figure out a few advanced features of fluent interfaces.

Below you'll see some sample code that I created in another thread: link text

    public class Coffee
 {
   private bool _cream;

   public Coffee Make { get new Coffee(); }
   public Coffee WithCream()
   {
     _cream = true;
     return this;
   }
   public Coffee WithOuncesToServe(int ounces)
   {
     _ounces = ounces;
     return this;
   }
 }

var myMorningCoffee = Coffee.Make.WithCream().WithOuncesToServe(16);
sam
A: 

With a fluent API:

myCar.SetColor(Color.Blue).SetName("Aston Martin");

Check out this video http://www.viddler.com/explore/dcazzulino/videos/8/

Leandro A. Boffi