Denis Dollfus' Blog

Fluent interface fashion victims

Les interfaces "qui nous parlent", ou Fluent Interfaces, sont à la mode, et comme toutes les modes IT on peut déjà prévoir qu'il y a aura des excès dont on aura à souffrir. Pour mémoire XML nous avait amené une épidémie de xml-ite aigue, caractérisée essentiellement par des noeuds XML en lieu et place des entités, des repository XML plutôt que des SGDB, et des transformations XSLT pour la logique métier et la création des vues. Sharepoint par exemple, dont la version beta que j'avais testée aux alentours de 2000 reposait largement sur XML/XSLT, commence à peine à s'en remettre.

A trop haute dose, quels peuvent être les effets indésirables des Fluent Interfaces ?

• Des interfaces tortueuses, difficiles à appréhender parce que passées au moule de la Fluent Interface sans que le domaine modélisé s'y prête. A titre d'exemple, une API de construction de documents XML gagne-t-elle à être "fluide" ? Pour ma part j'ai l'impression que le phrasé naturel amène un gain en lisibilité quand les sujets, verbes et compléments ont un sens précis (les Call() et Expect() de Rhino Mocks), moins quand ils sont génériques (les Nodes() et Attributes() d'un XML Builder).
• Un refactoring compromis. Une des bases des méthodes de développement agiles est le refactoring. Mais quand le code dupliqué se trouve enfoui au milieu d'une longue phrase fluente, il devient difficile de le factoriser. En tout cas les outils de refactoring intégré aux IDE, que ce soit Resharper ou le refactoring natif de Visual Studio ne peuvent pas appliquer un "extract method" sur ceci :

  XmlOutput xo = new XmlOutput()
      .XmlDeclaration()
      .Node("root").Within()
          .Node("user").Within()
              .Node("username").InnerText("orca")
              .Node("realname").InnerText("Mark S. Rasmussen")
              .Node("description").InnerText("I'll handle any escaping (like < & > for example) needs automagically.")
              .Node("articles").Within()
                  .Node("article").Attribute("id", "25").InnerText("Handling DBNulls")
                  .Node("article").Attribute("id", "26").InnerText("Accessing my privates")
                  .EndWithin()
              .Node("hobbies").Within()
                  .Node("hobby").InnerText("Fishing")
                  .Node("hobby").InnerText("Photography")
                  .Node("hobby").InnerText("Work");

  Ca devient aussi facile à refactorer qu'un roman aux phrases trop longues.
• Une lecture pas si évidente. Paradoxalement, il se pourrait bien que l'objectif initial de lisibilité soit manqué par excès de Fluent Interfaces. D'habitude (si seulement c'était une habitude), la lisibilité d'un logiciel est en grande partie déterminée par la clarté des noms de méthodes et de variables. Ou à défaut, et particulièrement dans le cas de méthodes trop longues candidates au refactoring, par des commentaires. Dans le cas d'une Fluent Interface, l'exemple précédent le montre bien, le risque est que le développeur se repose entièrement sur la "fluency" de l'API, et oublie les commentaires et le découpage en méthodes courtes et "parlantes".

Donc, à consommer avec modération, comme d'hab.

Fluent Interface : exercice

Suite à ce billet, voici ma première expérience (solutionVS 2008) avec les Fluent Interfaces. C'est une implémentation de l'exercice proposé par Michael Feathers, qui consiste à exposer les entiers sous forme littérale.

Exercice suffisant pour constater qu'il vaut mieux s'y aventurer avec méthode, ce qui n'a pas été mon cas. Dans l'implémentation que je vous propose, on peut aller jusqu'aux milliers, en écrivant des choses comme :

Assert.AreEqual(9210, FluentNumber.Nine.Thousand.Two.Hundred.And.Ten.ToInt());
Assert.AreEqual(92713, FluentNumber.Ninety.Two.Thousand.Seven.Hundred.And.Thirteen.ToInt());
Assert.AreEqual(700000, FluentNumber.Seven.Hundred.Thousand.ToInt());
Assert.AreEqual(777000, FluentNumber.Seven.Hundred.And.Seventy.Seven.Thousand.ToInt());
Assert.AreEqual(712713, FluentNumber.Seven.Hundred.And.Twelve.Thousand.Seven.Hundred.And.Thirteen.ToInt());
Assert.AreEqual(218001, FluentNumber.Two.Hundred.And.Eighteen.Thousand.One.ToInt());

Intellisense : pas trop mal, les 'teens' (thirteen, forteen...) n'apparaissent pas. Mais Hundred ne devrait pas apparaitre.

L'auto-completion fonctionne assez bien (cf. screenshot). Mais on peut quand même écrire des choses aberrantes :

FluentNumber.One.Thousand.One.Thousand.ToInt();

Pas facile à corriger... Etes-vous tenté par le défi ?

FluentNumbers.zip (VS 2008)

Fluent Interfaces (do you speak API ?)

Pour l'essentiel, le pattern des interfaces dites "fluentes" consiste à proposer aux développeurs d'écrire du code dont le phrasé ressemble au langage naturel.

Par exemple ce phrasé fluide (exemple tiré du site de Martin Fowler):

	TimeInterval meetingTime = fiveOClock.until(sixOClock);

exprime la même chose que cette version plus classique :

TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

L'usage du mot 'until' (jusqu'à), courant dans la vraie vie, plutôt rare en programmation, fait la différence. De façon générale, les Fluent Interfaces privilégient l'emploient de méthodes au nom simples et issus du langage courant.

Deux exemples pour fixer les idées.

1. Rhino Mocks, framework open-source de mocks dynamiques développé par l'inévitable Ayende, permet d'écrire ça dans un test unitaire :

	Expect.Call(myObject.Concat("a","b")).Return("ab");

Joli non ?

Si on portait cette Fluent Interface en français, ça donnerait quelque chose comme :

 	JeMAttendsACeQue.CetAppel(monObjet.Concat("a","b")).Retourne("ab");

2. ReadableRex, API qui encapsule la complexité des expressions régulières :

    Regex socialSecurityNumberCheck = new Regex(Pattern.With.AtBeginning

            .Digit.Repeat.Exactly(3)

            .Literal("-").Repeat.Optional

            .Digit.Repeat.Exactly(2)

            .Literal("-").Repeat.Optional

            .Digit.Repeat.Exactly(4)

            .AtEnd);

Implémentation

Dans les grandes lignes, l'implémentation d'une Fluent Interface en elle-même n'a rien de sorcier et consiste souvent à retourner dans les méthodes et accesseurs le contexte en construction. Par exemple :

	public class Configuration
	{
		string color;
		int height;
		Configuration Color(string color)
		{
			this.color = color;
			return this;
		}
		Configuration Height(int height)
		{
			this.height = height;
			return this;
		}
	}

Dans le détail, développer une Fluent Interface peut s'avérer extrémement complexe. La complexité tient à l'inconsistance fréquente du langage naturel. Qu'il s'agisse de l'anglais ou du français, la grammaire qui le définit regorge de contradictions, d'exceptions et d'effets de contexte.

Défi

Pour vous en convaincre, essayez d'implémenter une API fluente d'expression des nombres littéraux tel celui suggéré par Michael Feathers, et dont voici un aperçu des spécifications :

  Assert.AreEqual(1, (int)FluentNumber.One);
  Assert.AreEqual(23, (int)FluentNumber.Twenty.Three);
  Assert.AreEqual(912, (int)FluentNumber.Nine.Hundred.And.Twelve);
  Assert.AreEqual(777000, (int)FluentNumber.Seven.Hundred.And.Seventy.Seven.Thousand);

Ce que ne dit pas cet essemble de tests à faire réussir, c'est que l'autocompletion doit aussi fonctionner au mieux : taper 'Twenty' doit déclencher les propositions 'One', 'Two', ... 'Thousand" et 'Hundred', mais ni "Twenty" et autres dizaine, ni 'Thirteen' et autres 'teens'. C'est sûrement un excellent exercice pour appréhender les difficultés de développement d'une Fluent Interface.

Serez-vous capable de développer une API robuste vis-à-vis des tournures aberrantes telles que

	FluentNumber.One.Thousand.One.Thousand

Un vrai travail de linguiste...

Liens :

• Martin Fowler, Fluent interface
• Ayende, Rhino Mocks
• Joshua Flanagan, readable regular expressions