What advantages does method chaining have over plain imperative method calls?

Question

Look at this example code, from a Telerik MVC grid:

<% Html.Telerik().Grid(Model.InstallerList)
    .Name("InstallerGrid")
    .DataKeys(key => key.Add(c => c.InstallerID))
    .Columns(column =>
    {
        column.Template(action =>
            {%>
                <%= Html.ActionLink("Edit", "Edit", new{ id = action.InstallerID}) %> 
            <%});

        column.Bound(model => model.CompanyName);
        column.Bound(model => model.EmailAddress);
    })
    .Scrollable(scrolling => scrolling.Enabled(true))
    .Pageable(paging => paging.Enabled(true))
    .Sortable(sorting => sorting.Enabled(true))

    .Render(); %>  

Now, what is better about that than doing it like this:

<%
    var grid = Html.Telerik().Grid(Model.InstallerList);
    grid.Name("IntsallerGrid");
    grid.DataKeys(key => key.Add(c => c.InstallerID));
    // etc. etc.

    %>

Answer 1

These are called "Fluent Interfaces".

The supposed benefits are in readablity and discoverablity or code, though with good intellisense these may not give the most benefit.

Code becomes a lot more tight and the style of programming becomes more declarative - you say what you want to happen, instead of how you want it to happen. In this respect it helps with abstraction.

In terms of the results - no difference. It is just a matter of personal preference, and Telerik as a vendor offer as much choice as makes business sense.

Answer 2

There's no real difference, in this case, they just let you chain by returning the reference. The advantage? It's more terse and you don't have to maintain a reference yourself, other than that it's more about style than anything else.

When the Telerik guys converted to jQuery (which also chains) for their client-side script in many of their components fluent interfaces started showing up for them, guess they just liked the style and offered it as an option.

Now in other cases one method may return a reference or a type that's not the same as grid, for example how .OrderBy() returns an OrderedQueryable rather than just a Queryable, in those cases there is a potential difference in behavior, because you're not setting grid = the result in your example for each statement.

Answer 3

Ditto " People refer to these as "Fluent Interfaces". "

A great benefit is to avoid unnecessary parameters in methods, especially constructors. For example a cake can have icing, and icing can have words written on it.

Do you go for

  Cake cake = new Cake( Icing.None, "" );  // no icing, no words
  Cake birthday = new Cake( Icing.None, "Happy Birthday");  // invalid option!

or lovely Fluent style;

  Cake cale = new Cake();  // No icing, no words
  Cake birthday = new Cake().Icing(Icing.Chocolate).Word("Happy Birthday"); 

Answer 4

Fluent interfaces are meant to be a type of internal domain specific language. When implemented well they can read like a natural language sentence.

There's a really good write-up on Martin Fowler's bliki that covers the pros and cons in detail.

Note that Fowler (who came up with the name) recommends that the fluent interface be layered on top of a more standard API. Fluent interfaces break CommandQuerySeparation.

Answer 5

The return type that those methods chain may not necessarily be the original grid. In addition, not all of them may be easily expressible or useful after you're finished with them. Using a method chain keeps things tight and easy to change in the future.