Salut, c'est Nico de Code Garage.
Code Garage, qu'est-ce que c'est ?
C'est un site qui est rempli de ressources gratuites et de formation pour tous les devs,
les développeurs et les développeuses qui souhaitent s'améliorer, continuer de progresser
et passer de juniors à experts.
Aujourd'hui, on va se retrouver pour un nouvel épisode du podcast et on va parler du sujet
qui est le dry programming, le principe dry.
Le principe dry, qu'est-ce que c'est ?
En développement logiciel, il y a plein de principes de programmation qui permettent
de garder un code fonctionnel, dans le sens le code fonctionne, compréhensible et surtout
maintenable.
C'est ce qu'on regroupe en général dans le concept de code propre.
Et un de ces principes-là s'appelle dry sec en anglais et c'est un acronym qui veut
dire don't repeat yourself.
Et évidemment, son titre résume plutôt bien la chose, mais on va découvrir le concept
un petit peu plus en détail et voir de quoi il est constitué.
Le principe dry, il a été introduit en 1999 par Andy Hunt et Dave Thomas dans un livre
qui s'appelle de programmatiques, de pragmatiques, pardon, programmeurs.
Il rassemble en gros ce livre plein de concepts et astuces pour produire de meilleurs logiciels.
Alors meilleur, ça veut pas forcément dire plus rapide, mais surtout plus durable.
Et un des concepts de ce livre, c'est la phrase don't repeat yourself, donc ne te répète
pas en français.
Et ça deviendra un des principes de programmation les plus célèbres et les plus connus.
L'objectif de ce concept, c'est d'éliminer ou d'éviter du moins toute répétition
superflu dans un code appartenant à la même logique.
Ça veut dire qu'on va modifier notre code pour l'optimiser, le rendre plus lisible,
compréhensible et intuitif, pour aussi éviter les erreurs qui sont dues à la recopie,
parce que quand on recopie des choses, on a beaucoup de chances de se tromper, d'éviter
les oublies et de réduire le temps de développement.
Donc pour mettre en place ce principe, Hunt et Thomas, il s'appuient sur deux concepts
importants qui sont l'abstraction et la normalisation des données.
En créant suffisamment de couches d'abstraction, ça peut être des classes, des fonctions,
etc., on sera capable de baisser le nombre d'opérations logiques différentes dans
notre code.
Et la normalisation des données, ça offrira la possibilité de passer justement par ces
opérations existantes sans avoir à en créer des nouvelles.
Alors il faut savoir que l'abstraction et la normalisation, selon l'architecture de
notre code, ça peut plus ou moins se ressembler ou être très proche.
Ces deux concepts qui sont assez proches et qui s'imbriquent, je vais essayer de les
séparer, mais il faut garder en tête que ces deux concepts qui sont quand même très
proches.
D'abord, on va parler de la normalisation.
Je vais vous donner des exemples.
Donc un exemple très simple, on a deux classes qui sont caractérisées par un certain nombre
de propriétés en commun.
Donc par exemple, on a la classe user avec les propriétés FirstName, LastName, Email
et Job.
Et à côté, on a une classe admin avec les propriétés FirstName, LastName, Emails,
Email et Roles cette fois-ci.
Ici, la normalisation des données, ça passera par un simple héritage.
On va créer une classe mer qui s'appelle Account dans lequel on va mettre les propriétés
FirstName, LastName et Email et on va garder notre classe user.
Simplement, on va la faire ériter de la classe Account et en plus, elle aura une propriété
bien à elle qui s'appellera Job.
Et pour la classe admin, on va aussi la faire étendre de la classe Account, mais en ayant
une seule propriété distincte qui sera Roles.
Ici, la classe Account, ça nous permet d'éviter d'enlever la redondance du code.
Donc, le résultat est plus lisible, plus court et pour les prochaines méthodes qu'on
va écrire, qui seront communes à User et Admin, ça nous permettra de les écrire
qu'une seule fois puisque elles seront dans la classe Account.
Maintenant, on va parler de l'abstraction.
Si on reprend notre classe User qu'on a définie précédemment, on va imaginer qu'on a deux
méthodes qu'on doit implémenter.
Une pour inscrire un utilisateur sachant qu'on aura que son adresse email, ça veut
dire que toutes les autres informations qu'on aura devront être mises par défaut puisque
on ne les a pas, on n'a que son email.
Ça, c'est une contrainte métier.
Et on va avoir une autre méthode pour réinitialiser le profil à l'exception de l'email, un
petit peu comme pour anonymiser le profil.
On pourrait avoir deux méthodes.
Simplement, avoir une méthode create dans laquelle on passe un email, on vient mettre
l'email dans l'objet et on va passer toutes les autres propriétés avec une valeur anonymos
pour pouvoir l'afficher.
Donc, FirstName sera égal à Anonym, LastName égal à Anonym, un avatar par défaut et le
job qu'on ne connaît pas à unknown.
Ensuite, on vient sauvegarder cet utilisateur.
Et on aurait une deuxième méthode qui s'appeler RISET profile où on viendrait faire si l'utilisateur
va remplir son lastname, son firstname, etc.
Et bien, on vient les remettre par défaut.
Donc, on va venir faire FirstName égal à Anonymus, LastName égal à Anonymus, avatar
égal à avatar par défaut, etc.
Et bien, tout simplement, on va utiliser une couche d'abstraction qui va être une nouvelle
méthode qui va s'appeler SetDefaultField.
Et donc, dans SetDefaultField, c'est là qu'on va venir remettre le firstname à Anonym,
LastName à Anonym.
Et au lieu de rappeler toutes ces lignes-là dans Create et dans RISET, on va simplement
appeler la méthode SetDefaultField dans les deux méthodes.
Donc, ça permet de rendre le code plus lisible, ça facilite la maintenance parce qu'on
pourra réinitialiser plus tard d'autres attributs de la classe beaucoup plus facilement.
On n'aura pas besoin de les RISET dans les deux méthodes, mais dans une seule méthode
qui est appelée par les deux autres.
En plus, le nomage, ça a rendu le fonctionnement beaucoup plus clair parce qu'avant, on avait
un Create, une méthode Create, mais on ne savait pas qu'on mettait des champs par défaut.
Ici, on a une méthode qui s'appelle SetDefaultField, donc ça devient tout de suite beaucoup plus
clair.
Avant, il aurait fallu lire le contenu de chacune des méthodes pour comprendre ce qu'ils
faisaient.
Là, c'est tout de suite plus clair.
J'espère que ce concept vous sera un petit peu plus clair.
Alors, juste une petite info en plus.
Quand on ne respecte pas le principe dry, parfois, on parle d'un code wet.
Wet, ça a aussi été, on va dire, décomposé en un acronyme qui serait appelé write everything
twice.
Certaines personnes disent que c'est un principe de programmation.
En réalité, ce n'est pas vraiment un principe.
C'est plutôt un surnom qu'on donne à une mauvaise mise en pratique de dry.
Mais voilà, simplement, pour vous dire, parfois, vous pouvez trouver l'inverse de dry qui
s'appelle wet.
Certains considèrent comme un principe de programmation.
Moi, de ce que j'ai pu voir, c'est plutôt une mauvaise interprétation, mais voilà,
c'était un petit détail.
J'espère que cet épisode vous aura été utile.
Moi, je vous dis à la semaine prochaine pour un prochain épisode du podcast.
Et si c'est possible et que vous écoutez, par exemple, sur iTunes, ce podcast, n'hésitez
pas à laisser cinq étoiles.
Ça permet d'augmenter la visibilité de chaque épisode du podcast et donc aussi de
mettre en avant notre travail.
Je vous souhaite une bonne semaine et à la semaine prochaine.