La mauvaise bonne idée des interfaces fluides

Publié le 08 oct 10 à 09:02 | Catégorie : Développement Web | 8 commentaires

Je constate surtout depuis deux ou trois ans une nouvelle tendance en terme de pratique de développement qui était pourtant partie d’une bonne idée : les interfaces fluides (ou fluent en anglais). Cette pratique est également connue sous le nom de chainage de méthodes (ou method chaining en anglais). Je crois que je l’ai découverte pour la première fois dans du code Javascript faisant appel à la librairie jQuery. Il me semble cependant que cette pratique a plus d’inconvénients que d’avantages.

En fait, il faut bien comprendre que le programmeur est un être paresseux et en constante recherche de solutions pour faciliter son travail. Dans cette quête sans relâche, après avoir découvert les vertus de la programmation objet, il a inventé le fabuleux concept d’interface fluide : la possibilité d’enchaîner différentes méthodes depuis la même instance d’une classe. Concrètement, au lieu d’écrire :

1
2
3
4

var section = $('.section:first');
section.show();
section.find('close');
section.remove();

Il lui suffit maintenant de taper :

1

$('.section:first').show().find('.close').remove();

Plus besoin de répéter le nom de l’objet ! L’avantage immédiat est un gain de temps et une écriture très… fluide. Mais outre le fait que cela peut pervertir le modèle objet (puisqu’il faut alors faire en sorte de retourner l’instance courante à la fin de chaque méthode), cette approche a pour moi une contrepartie non négligeable : il est beaucoup plus difficile de déchiffrer le code.

Pour prendre un exemple très concret, voici un morceau de code de Magento :

1
2
3
4
5

$this->setChild($attribute->getAttributeCode().'_filter',
    $this->getLayout()->createBlock($filterBlockName)
        ->setLayer($this->getLayer())
        ->setAttributeModel($attribute)
        ->init());

Je ne sais pas vous, mais je trouve qu’il est vraiment délicat de comprendre rapidement ce que réalise cette succession d’instructions. En plus, je me rappelle être tombé dans des cas où le type des instances retournées variait au beau milieu de la chaine de méthodes. L’autre inconvénient est qu’il devient également très compliqué de discerner les modifications apportées à un tel code dans un gestionnaire de versions dans le cas où plusieurs instructions sont sur une même ligne, puisque toute la ligne sera surlignée lors d’une comparaison.

La meilleure façon d’utiliser cette manière de coder est en fait de bien respecter l’indentation et les retours à la ligne :

1
2
3
4
5
6

$mail = new Zend_Mail();
$mail->setBodyText('This is the text of the mail.')
     ->setFrom('somebody@example.com', 'Some Sender')
     ->addTo('somebody_else@example.com', 'Some Recipient')
     ->setSubject('TestSubject')
     ->send();

Dans ce cas, il est vraiment possible de rendre le code plus léger. Comme la plupart des concepts, peut-être que le véritable problème réside dans son application ? Mais je trouve que les risques de mauvaises utilisations sont trop importants par rapport aux effets escomptés.

A lire également

Les visiteurs qui ont vu cette page ont consulté ensuite :

A savoir

La rédaction de cet article a nécessité 1 heure et 11 minutes. Si vous le souhaitez, vous pouvez être prévenu de la parution de nouveaux articles en vous abonnant par RSS ou par email.

8 commentaires à propos de “La mauvaise bonne idée des interfaces fluides” :

  1. Un autre inconvénient est qu’un tel code est relativement illisible dans un débugger.
    Je pèche en général dans l’excès inverse en ajoutant systématiquement des variables locales intermédiaires, mais ce n’est surement pas très performant sur un langage non compilé.

    Ce style me fait penser a du code Perl dense. Un peu trop.

    Sylvain le 8 octobre 2010 à 09:14 (#1)

  2. ceci dit, je veux bien croire que les developpeurs soient paresseux (j’en suis :D) mais souvent, les codes chaînés font suite à un besoin d’alléger le poids du script pour ne parler que du javascript et une fois passé dans un minifier, on a effectivement un code (encore un peu) lisible pour un humain mais il est vrai un peu dense.
    Heureusement, les “unobfuscateurs” ou “unminifiers” existent comme celui-ci (http://jsbeautifier.org/) et pleins d’autres astuces comme ceux-là (http://www.mikepostma.com/blog/unobfuscate-javascript).

    Hernandez G le 8 octobre 2010 à 11:04 (#2)

  3. Si Javascript a aujourd’hui popularisé le chaînage de méthodes, c’est outre la rapidité d’écriture, aussi parce que le poids du code source s’en trouve réduit.
    Car bien que le haut débit se soit généralisé, ça reste un paramètre important à prendre en compte, surtout pour les applications mobiles.

    Par contre, côté PHP, je l’utilise avec modération uniquement pour des chaînages brefs. Pour les chaînages à rallonge, imbriqués, etc… je préfère opter pour l’écriture habituelle surtout pour faciliter une relecture ultérieure.

    Geoffray le 8 octobre 2010 à 11:17 (#3)

  4. Effectivement JS à une part de responsabilité. Mais la bonne solution serait plutôt d’utiliser un outil de compression du code JS et de laisser le source lisible.

    Sylvain le 8 octobre 2010 à 12:07 (#4)

  5. (à ce rythme là autant ne pas mettre de commentaires non plus :-) )

    Sylvain le 8 octobre 2010 à 12:07 (#5)

  6. Le problème du code Magento présenté n’est pas vraiment l’usage des interfaces fluides mais l’imbrication d’appels à des méthodes.

    Avec une indentation correcte les interfaces fluides sont généralement plus claires, car moins verbeuses, que l’usage de variables intermédiaires.

    Jean-Marc Fontaine le 8 octobre 2010 à 12:18 (#6)

  7. Ca me fait penser à une phrase qui revenais souvent en conférence il y a 10/15 ans :

    “Si les développeurs étaient fainéants, qui serait là pour faire évoluer le WWW”

    Personnellement, mais ça ne concerne que moi, je n’utilise aucune librairie externe et programme toutes mes classes (autant JS que PHP) à la mano, au moins je suis sur du cheminement de l’exécution et de ne pas avoir de méthode obsolète dans le temps.

    @Hernandez G : Tu aura beau chaînés tes actions, avec JQuery tu ne gagnera aucun temps de traitement, juste au mieux une ligne de code (à multiplié par le nombre de fois).

    Sylvain à fait une très bonne remarque, le meilleur reste de mimifier son code avant la MEP, et de garder des versions sources clean. Alors en fonction des outils utilisés il faut coder différemment (sinon ça bousille tout), mais on s’y fait vite.

    Tim le 10 octobre 2010 à 00:57 (#7)

  8. C’est vrai, ça me fait penser qu’il faudrait que je fasse un autre article pour parler de la notation raccourcie pour certaines règles CSS : encore un vrai faux problème.

    Stéphane le 10 octobre 2010 à 15:42 (#8)

Ajouter un commentaire

Les informations obligatoires sont indiquées par une étoile rouge *.


Par contre, il y a encore des trucs qui ne marchent pas. Par exemple il a compris 'DesignS' au lieu de 'Design'.

Articles Récents

Les derniers articles publiés

A Propos

Je m’appelle Stéphane Thomas et je suis Ingénieur Senior expert dans le développement d'applications web complexes. Etant également un peu Entrepreneur, j'ai tenté l'aventure de la création d'un nouveau service Internet appelé Loomiz. Je suis maintenant le cofondateur d'Hitomi Studio, un studio de développement spécialisé dans la réalisation de sites ecommerce haut de gamme pour de jolies marques.

Lire la suite…