Des anti-patterns pour les fêtes

En fin d’année les bêtisiers étant généralement à l’honneur, c’est l’occasion de présenter des exemples de choses à ne pas faire ou à éviter dans le développement d’un projet.

Le God Object

Le god object est une forme de programmation particulière s’appuyant sur le principe « Dieu est omniscient et omnipotent ». En pratique, on se retrouve avec une seule classe qui sait tout (elle contient tout l’état du programme) et qui fait tout (elle contient tous les traitements et algorithmes du programme). Dans certains cas, d’autres modules sont articulés autour du god object, mais sont tellement dépendants de lui que ce dernier joue effectivement le rôle d’un dieu.

Les principales conséquences sont la difficulté à comprendre (la volumétrie de code est trop abondante pour être appréhendée par l’esprit d’un développeur simple mortel, en d’autres termes les voies du Seigneur deviennent vraiment impénétrables), et surtout à maintenir le code (la moindre modification devient un casse-tête et peut avoir des conséquences parfois imprévisibles sur l’ensemble du programme).

Cet anti-pattern va bien évidemment à l’encontre du Single Responsibility Principle.

La coulée de lave

La coulée de lave se produit lorsque des choix de design fonctionnels ou techniques peu aboutis se retrouvent en production. Alors qu’il existait encore une certaine fluidité dans ces choix, le fait de livrer en production solidifie le design et empêche toute modification. D’où la métaphore géologique.

Elle se produit également lorsque des choix sont effectués à des endroits inappropriés : par exemple, en limitant la taille d’une colonne en base pour correspondre à des limitations de format d’export de données. Si par la suite on veut augmenter la taille de cette colonne, les exports ne seront plus conformes, obligeant à tous les reprendre. On s’expose ainsi à un perte de données, certaines valeurs finissant tronquées.

Trop de paramètres (aka le Scolopendre)

Dans le cas de traitements ou d’objets complexes, nous sommes rapidement tentés d’introduire de nombreux paramètres aux constructeurs ou aux méthodes. Après tout, le langage Java autorise jusqu’à 255 paramètres, donc pourquoi s’en priver ? Pour plusieurs raisons :

  • l’appel d’une méthode aux nombreux paramètres ne met pas en évidence le rôle de chacun (notamment avec des valeurs booléennes ou telles que null) et oblige à naviguer jusqu’à la définition de la méthode; et encore faut-il que les paramètres soient suffisamment bien nommés et documentés;
  • lors de l’appel, on se retrouve fréquemment confronté à des problèmes de compilation liés à un mauvais nombre de paramètres ou à des erreurs de typage; attention également aux problèmes de surcharge;
  • l’introduction de nouveaux paramètres entraîne une modification de la signature de méthode, et s’avère particulièrement pénible lorsque ces paramètres sont transmis dans une cascade d’appels de méthodes;
  • globalement, le code est beaucoup moins lisible.

Heureusement, il existe quelques façons de s’en sortir :

  • utilisation de patterns de type Builder, avec des appels dits fluent : on l’utilisera essentiellement pour remplacer des constructeurs trop verbeux, chaque élément de configuration de l’objet passant par une méthode du Builder.
  • utilisation de structures regroupant les paramètres : il peut s’agir de maps, ou encore d’objets plus complexes (ex: classe ConnectionParameters).

Laisser un commentaire