dans Programmation 101
Le code qui pue – L’obsession des primitives
Un Code Smell (code qui pue) est une caractéristique subjective du code source qui indique qu’il y a potentiellement un problème avec ce dernier. Je commence donc cette série d’articles qui traitera de ces caractéristiques et fournira des outils pour les identifier facilement, les régler et ne plus jamais avoir à s’en soucier. Je vous présente donc aujourd’hui le premier de la série qui traite de l’obsession des types primitifs (primitive obsession).
Important : Lorsqu’on parle de caractéristiques subjectives, ça veut dire que :
- C’est une opinion
Et que ça peut ou pas s’appliquer à :
- une certaine application
- un certain langage
- certains écosystèmes applicatifs
- certaines équipes de développement
Qu’est-ce que l’obsession des types primitifs
Ça ne devrait pas être un secret, les types primitifs dans certains langages orientés-objet sont les seuls éléments d’un logiciel qui ne peuvent pas respecter les principes OO. Par exemple, en Java, on ne peut pas faire :
Ceci est principalement dû au fait que Java n’est pas un langage orienté-objet pur comme l’est Python par exemple. Donc en Java, on dit : « Tout est un objet, sauf les types primitifs »
L’obsession des types primitifs est un comportement des développeurs qui ont tendance à utiliser ces derniers dans le code au lieu d’utiliser des objets. Voici un exemple qui fait du sens :
Cette classe est l’exemple le plus commun et le plus fragrant. Qu’arrive-t-il à votre 2,147,483,648e utilisateur? Ça parait beaucoup? Parlez-en à Twitter 😉
Le problème
Principalement, le problème avec un type primitif c’est que ce n’est pas un objet (duh!). Impossible de le mocker, d’en faire une extension, de changer son type sans impact, etc..
Mais concrètement…
Je prends l’exemple de Twitter. Ils ont utilisé un entier pour identifier de façon unique un utilisateur. Éventuellement, ils se sont rendus compte qu’ils allaient atteindre la limite de l’entier et on du changé pour un long… Imaginez le bordel dans le code 😀
Non seulement, mais toutes les librairies tierces qui utilisaient l’API de Twitter ont dû aussi changer…
Comment on spot le problème?
Si vous voyez un type primitif, vous êtes à risque.
Mais Sylvain, comment tu veux que je code sans types primitifs?
Ah! Il faut faire attention. Je ne dit pas d’arrêter d’utiliser les types primitifs, je dis simplement qu’il faut se poser la question : Est-ce que je peux remplacer mon type primitif par un objet?
Si on reprends l’exemple ci-dessus, voici une implémentation simple qui règle une partie des problèmes. Suffit d’y penser au début du développement :
Oui mais, Sylvain, je ne veux pas qu’on me passe un float ou un double!
À voir… À valider… À considérer!
Comment on applique ça?
Si la solution simple est d’utiliser un objet comme démontré ci-dessus, il se peut que ce ne soit pas toujours possible d’utiliser les types fournis par le langage de programmation. Il est vrai qu’on ne veut pas nécessairement permettre des IDs d’utilisateur à virgule flottante. L’encapsulation devient donc notre allier!
Posez-vous la question, vous y répondrez seuls :
Est-ce que l’identifiant de l’utilisateur devrait être un chiffre?
Réponse : Oui
Ou encore mieux :
Comment devrait-on identifier un utilisateur de façon unique?
Réponse : Avec un identifiant unique
Voici un exemple :
Mais, Sylvain, t’as encore un Long!
Bien entendu! Mais l’information qu’on propage partout dans le code n’est pas le Long, mais bien UserId. Ceci nous permet de faire un sous-classe de l’identifiant dans le cas ou il faudrait changer le type de l’identifiant, nous permettant de respecter le principe ouvert/fermé (OCP) des principes SOLID.
Conclusion
Voilà donc à quoi ressemblera cette série. Nous verrons ensemble les code smells les plus fréquents ainsi que des techniques pour identifier les symptômes et quelques trucs pour éviter de tomber dans le piège.
Si vous avez aimé, inscrivez-vous au blogue! Vous recevrez un courriel à chaque publication pour ne rien manquer. Et si vous voulez être vraiment généreux, partagez l’article avec vos collègues et sur vos réseaux sociaux 🙂
Ciao!
Commentaires
2 commentaires
Merci pour l’article très intéressant de voir en plus la relation avec les principes Solid que je trouve très pertinent même si j’ai de la difficultés a les mettre en pratique!
Merci pour ton commentaire 🙂 Si je n’ai qu’un conseil pour toi, c’est d’expérimenter avec des projets personnels. Essaie de briser les principes et de voir l’impact quand tu essaies de faire un changement. Un bon projet pour expérimenter, c’est le jeu de la vie :
https://rosettacode.org/wiki/Conway%27s_Game_of_Life
Essaie avec l’état (vivant/mort) stocké en booléen (primitif), puis réessaie en utilisant le polymorphisme (AbstractCell, LiveCell, DeadCell).
Cheers !
Laisser un commentaire