PHPTour 2017 : Les objets calisthéniques en PHP

Lors du PHP Tour, j'ai suivi le talk de MAXENCE POUTORD sur le thème "MAKE YOUR CODE GREAT AGAIN WITH THE OBJECT CALISTHENICS".

Cette philosophie de développement tient en 9 règles simples initialement rédigées en anglais que sont :

  • Règle 1 : N'avoir qu'un seul niveau d'indentation par méthode
  • Règle 2 : Ne pas utiliser de else
  • Règle 3 : Encapsuler tous les types primitifs et string
  • Règle 4 : Un seul point / une seule flèche par ligne
  • Règle 5 : Ne pas utiliser d’abréviation
  • Règle 6 : Garder des entités petites
  • Règle 7 : Ne pas créer de classe avec plus de deux variables instanciées
  • Règle 8 : Utiliser des classes de collection
  • Règle 9 : Ne pas créer de getter/setter aux propriétés

Ce qu'il faut comprendre, c'est que l'on rencontre assez souvent du code difficile à comprendre, tester et maintenir.
Beaucoup pensent faire du bon travail, appliquer un design Orienté Object sur son code (moi le premier) mais en fait on se retrouve à toujours faire du code procédural encapsulé dans de l'objet.
Un bon code devrait avoir une forte cohésion, un couplage faible, pas de duplication, de l'encapsulation, être testable et lisible simplement.
En fait, appliquer le principe SOLID, les design patterns et améliorer la qualité du code.

Pour expliquer les différentes règles :

Règle 1 : N'avoir qu'un seul niveau d'indentation par méthode
Les indentations font perdre en cohésion dans le code. Idéalement, il faudrait faire des méthodes de 15 lignes.
Chaque méthode ne devant avoir qu'une et une seule responsabilité. (design pattern Extract Method)

Règle 2 : Ne pas utiliser de else
L'utilisation du 'else' crée une nouvelle branche dans votre code plutôt que de le factoriser en une meilleure solution.
Une solution simple peut être l'utilisation d'une guard clause ou d'un early return ce qui permet d'avoir un comportement par défaut. (design pattern state / strategy)

Règle 3 : Encapsuler tous les types primitifs et string
Utiliser des objets représentant la donnée plutôt qu'un type primitif donne plus d'informations au compilateur/interpréteur et au développeur sur ce qui est attendu (design pattern)

Règle 4 : Un seul point / une seule flèche par ligne
La multiplication des points/flèches rendent plus difficile la lecture du code afin de savoir qui prend la responsabilité de l'action.
Si tous les points/flèches sont connectés, c'est que votre objet va trop en profondeur pour atteindre un autre objet ce qui va à l'encontre du principe d'encapsulation. Manipulez ce à quoi vous pouvez directement accéder, pas plus.

Règle 5 : Ne pas utiliser d’abréviation
Les abréviations sont courantes lorsque l'on réutilise encore et encore le même nom de classe, méthode, variable. Mais cela peut apporter de la confusion et cacher des soucis de logique sur le code. Si l'on répète encore et encore un même mot, c'est que la méthode a peut être trop de responsabilités, que l'on duplique du code, qu'il manque une classe.

Règle 6 : Garder des entités petites
Les classes ne devraient pas faire plus de 15 lignes et les paquets ne devraient pas contenir plus de 10 fichiers.
Si une classe fait plus de 15 lignes, c'est qu'elle fait plusieurs choses donc elle est plus compliquée à comprendre et réutiliser. Des classes plus petites peuvent être plus facilement regroupées en fonction de leur comportement et créer des paquets plus censés.

Règle 7 : Ne pas créer de classe avec plus de deux variables instanciées
La majorité des classe ne devrait être responsable de l'état d'une seule variable, exceptionnellement deux.
Certaines classe maintiendront le statut d'une variable tandis que d'autre coordonneront deux variables différentes. Il faut éviter de mélanger ces deux responsabilités. (éviter le design pattern God Object)

Règle 8 : Utiliser des classes de collection
Une classe qui contient une collection ne devrait rien contenir d'autre, chaque collection devant avoir sa propre classe. Une collection a plusieurs comportements mais donne de nombreuses informations orientées pour le prochain développeur.

Règle 9 : Ne pas créer de getter/setter aux propriétés
Le but derrière cette règle est de dire ce que l'on veut faire, ne pas avoir à le demander. Ceci permet de réduire drastiquement le nombre d'erreurs et de mieux identifier l'endroit où l'on doit implémenter les features.

L'application stricte de ces règles ne peut se faire sur un projet existant, il faut l'appliquer dès le départ tant elles semblent extrêmes. Mais leur application permet d'améliorer nettement la qualité du code.
Selon Maxence, connaître ces règles est une bonne chose mais il ne faut pas les appliquer telles quelles, les adapter à son environnement.
J'ai eu du mal à voir quelles sont les spécificités pour le PHP liées à ce talk mais j'ai trouvé un projet github phpcs-calisthenics-rules toujours actif qui vous aidera à analyser votre code.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *