L'Open Closed Principle comme technique de développement logiciel

Quand je code, j'essaie autant que possible de prendre du recul sur mes choix même si ce n'est pas toujours facile dans le feu de l'action. J'ai toujours cette idée de pouvoir, au moins partiellement, formaliser des décisions qui relèvent bien souvent de l'intuition.

Bien sûr, il y a le TDD qui est une aide très précieuse. Mais, j'ai souvent l'envie de modifier du code existant avant d'écrire le test qui devrait être le 1er pas d'un cycle de TDD.

Ce n'est que récemment que j'ai identifié un pattern : je couple très souvent mon TDD avec une situation OCP.

L'Open Closed Principle, c'est le "O" de SOLID. Un élément de code bien conçu est ouvert aux extensions mais fermé aux modifications. On doit pouvoir étendre son comportement sans avoir besoin de modifier le code existant.

C'est rarement le cas car on ne peut pas savoir à l'avance quelles extensions seront utiles et il serait vain de prévoir dans notre code toutes les extensions futures possibles, y compris celles qui ne verront jamais le jour. Ça serait du temps perdu et ça compliquerait inutilement le code.

Et c'est là que je trouve le lien avec le TDD intéressant. Je me suis rendu compte que, sans trop vraiment y réfléchir, j'appréciais le TDD quand le code concerné respectait déjà l'OCP : on écrit un test et, pour le faire passer au vert, il suffit de rajouter du code, d'étendre le code existant sans avoir besoin de le modifier.

C'est la raison pour laquelle mon cycle de TDD contient bien souvent une étape préliminaire aux 3 étapes classiques :

  • Préfactor : on modifie le code visé pour le mettre en situation OCP
  • Red : on écrit un test qui ne passe pas
  • Green : on ajoute le code pour faire passer le test
  • Refactor

Et, en général, ça ne marche pas trop mal. Le danger, je pense, c'est de vouloir en faire trop lors du préfactor en imaginant les extensions qui seront utiles alors que seul le cycle de TDD pourra les mettre en évidence.

Cela m'amène donc aussi parfois aux phases Préfactor et Red qui vivent en parallèle. C'est à dire que le test rouge sert de guide à un remaniement de code qui doit, évidemment, laisser les autres tests au vert et qui doit pousser le code dans une situation où le test rouge pourra passer en ne faisant que rajouter du code à l'existant.

Je ne sais pas si tout cela est une bonne méthode mais en tout cas, ça fonctionne bien pour moi, en prenant bien soin d'avoir des cycles très courts.

Une réaction ? Un commentaire ? Rejoignez la discussion.   linkedin   twitter