Quels avantages le chaînage de méthodes a-t-il par rapport aux appels simples de méthode impérative?

Question

Regardez ce code par exemple, à partir d'une grille Telerik MVC:

<% 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(); %> 

Maintenant, ce qui est mieux à ce sujet que de le faire comme ceci:

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

    %> 

Answer 1

Les interfaces fluides sont conçues pour être un type de langage spécifique au domaine interne. Lorsqu'ils sont bien mis en œuvre, ils peuvent se lire comme une phrase en langage naturel.

Il y a un très bon article sur le bliki de Martin Fowler qui couvre les avantages et les inconvénients en détail.

Notez que Fowler (qui a inventé le nom) recommande que l'interface fluide soit superposée à une API plus standard. Les interfaces courantes se brisent CommandQuerySeparation.

Answer 2

Ceux-ci sont appelés "Fluent Interfaces".

Les avantages supposés sont en termes de readablity et de discoverablity ou de code, bien qu'avec une bonne intelligence ceux-ci ne donnent pas le plus d'avantages.

Code devient beaucoup plus serré et le style de programmation devient plus déclaratif - vous dites ce que vous voulez arriver, au lieu de comment vous voulez que cela se produise. À cet égard, il aide à l'abstraction.

En termes de résultats - pas de différence. C'est juste une question de préférence personnelle, et Telerik en tant que fournisseur offre autant de choix que de sens commercial.

Answer 3

Il n'y a pas réelle différence, dans ce cas, ils vous laissent la chaîne en retournant la référence. L'avantage? C'est plus concis et vous n'avez pas besoin de maintenir vous-même une référence, sauf que c'est plus une question de style qu'autre chose. Quand les gars de Telerik se sont convertis en jQuery (qui enchaîne aussi) pour leur script côté client dans un grand nombre de leurs composants, des interfaces fluides ont commencé à apparaître pour eux, ils ont juste aimé le style et l'ont proposé en option.

maintenant dans d'autres cas, une méthode peut renvoyer une référence ou un type qui est pas le même que grid, par exemple, comment .OrderBy() retourne un OrderedQueryable plutôt qu'un Queryable, dans ces cas, il y a une différence de potentiel de comportement, car vous ne définissez pas grid = le résultat dans votre exemple pour chaque instruction.

Answer 4

Ditto « Les gens se réfèrent à ces comme « Interfaces » Courant ».

Un grand avantage est d'éviter les paramètres inutiles dans les méthodes, en particulier les constructeurs. Par exemple un gâteau peut avoir du glaçage, et le glaçage peut avoir des mots écrits dessus.

Est-ce que vous allez pour

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

ou style belle Fluent;

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

Answer 5

Le type de retour que ces chaînes de méthodes ne sont pas nécessairement la grille d'origine. En outre, tous ne peuvent pas être facilement exprimables ou utiles après que vous en ayez fini avec eux. L'utilisation d'une chaîne de méthodes maintient les choses serrées et faciles à changer à l'avenir.