IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

N'appliquez pas prématurément le principe DRY (Ne vous répétez pas) à votre code
Car l'application trop rigide du principe DRY conduit à des abstractions prématurées et des changements futurs plus complexe

Le , par Jade Emy

150PARTAGES

13  0 
Selon Dan Maksimovich, il ne faut pas appliquer prématurément les principes DRY (Ne vous répétez pas) aux codes. L'application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.

Ne vous répétez pas (don’t repeat yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au sein d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.

La philosophie DRY est explicitée par la phrase suivante, formulée par Andy Hunt et Dave Thomas dans leur livre The Pragmatic Programmer : "Dans un système, toute connaissance doit avoir une représentation unique, non ambiguë, faisant autorité". Les auteurs appliquent ce principe pour inclure les bases de données, les plans de tests, le système de construction logiciel et même la documentation logicielle.

Lorsque le principe DRY est bien appliqué, la modification d'un élément d'un système ne change pas les autres éléments non liés logiquement. De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés. En utilisant les méthodes et les sous-routines dans leur code, Thomas et Hunt se reposent sur les générateurs de code source, les systèmes de construction automatique, et les langages de scripts pour respecter le principe DRY à travers les diverses étapes de construction d'un logiciel.

Cette philosophie prévaut dans l'architecture dirigée par les modèles, dans lequel les artefacts logiciels sont dérivés d'un modèle objet central décrit dans un langage tel qu'UML. Le code DRY est créé par transformation de données et les générateurs de code qui évitent au programmeur de copier-coller du code. Le code DRY facilite la maintenance de systèmes logiciels complexes, à partir du moment où les transformations de données sont faciles à créer et maintenir. Des outils tels que les annotations, XDoclet et XSLT sont des exemples de technique de codage DRY.

Un exemple de système requérant une duplication d'information sont les EJB 2.0 qui nécessitent une duplication d'information non seulement dans le code Java, mais aussi dans les fichiers de configuration. Des exemples de systèmes essayant de réduire la duplication d'information sont le framework web Django, Ruby on Rails et les EJB 3.0.


N'appliquez pas prématurément les principes DRY à votre code

Voici ce que Dan Maksimovich écrit sur la santé du code et l'application des principes DRY :

Nous sommes nombreux à avoir entendu parler des vertus de la méthode « Don't Repeat Yourself » ou DRY (ne pas se répéter). Faites une pause et réfléchissez : La duplication est-elle vraiment redondante ou la fonctionnalité devra-t-elle évoluer indépendamment au fil du temps ? Une application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.

Examinez attentivement si le code est réellement redondant ou s'il n'est que superficiellement similaire. Même si les fonctions ou les classes se ressemblent, elles peuvent servir des contextes différents et répondre à des exigences commerciales qui évoluent différemment au fil du temps. Réfléchissez à la manière dont l'objectif des fonctions se maintient dans le temps, et ne vous contentez pas de raccourcir le code. Lors de la conception d'abstractions, ne couplez pas prématurément des comportements qui peuvent évoluer séparément à plus long terme.

Quand l'introduction d'une abstraction nuit-elle à notre code ? Considérons le code suivant :


L'approche de droite semble violer le principe DRY puisque les contrôles ValueError sont identiques par coïncidence. Cependant, les tâches et les paiements représentent des concepts distincts avec une logique potentiellement divergente. Si la date de paiement nécessitait ultérieurement une nouvelle validation, vous pourriez facilement l'ajouter au code de droite ; l'ajouter au code de gauche est beaucoup plus invasif.

En cas de doute, séparez les comportements jusqu'à ce que suffisamment de modèles communs émergent au fil du temps pour justifier le couplage. À petite échelle, il peut être plus simple de gérer la duplication que de résoudre la complexité d'une abstraction prématurée. Aux premiers stades du développement, il convient de tolérer un peu de duplication et d'attendre avant de procéder à l'abstraction.

Les exigences futures sont souvent imprévisibles. Pensez au principe « You Aren't Gonna Need It » ou YAGNI. Soit la duplication s'avérera être un non problème, soit avec le temps, elle indiquera clairement la nécessité d'une abstraction bien réfléchie.
Source : Dan Maksimovich, Andy Hunt et Dave Thomas

Et vous ?

Pensez-vous que cet avis est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

L'utilisation de l'assistant d'IA GitHub Copilot pour la programmation entraîne une baisse de la qualité globale du code et une quantité importante de code redondant, selon une étude

7 signes révélateurs d'un code illisible : Comment identifier et résoudre le problème

« Un bon code est comme une lettre d'amour destinée au prochain développeur qui va le maintenir », estime Addy Osmani. L'ingénieur de Google montre les similitudes entre les deux

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 01/06/2024 à 11:58
De mon côté, j'ai plutôt tendance à écrire du code fortement typé tel que, quand un objet a un certain type, on a la garantie qu'il a passé certaines contraintes. Rappel : En Python, on peut utiliser les annotations de type pour avoir du typage statique.
Ici, j'aurais fait un type Deadline qui encapsule une date et heure. Si la date et heure est avant maintenant, le constructeur de Deadline lance une ValueError.
D'ailleurs, je n'aurais pas appelé directement datetime.now(), même si cela n'empêche pas d'automatiser les tests en Python qui permet de faire du monkey patching. Je préfère passer "maintenant" en paramètre. De manière générale, dans du code testable, je préfère rendre les entrées et sorties explicites via des paramètres que de faire du monkey patching.
Enfin, mon type Deadline n'aurait pas encapsulé directement le type datetime. Le problème du type datetime de la bibliothèque standard de Python est qu'il n'indique pas s'il inclut la timezone. En Python, il m'est déjà arrivé par erreur de comparer ou soustraire un objet de type datetime qui a une timezone et un autre objet de type datetime qui n'a pas de timezone, ce qui a lancé une exception. Pour éviter ça, j'encapsule le type datetime dans une autre classe qui ajoute un invariant selon lequel on a une timezone.
Finalement, le code que je décris est bien du DRY, mais la classe Deadline est bien séparée du reste.
Remarque 1 : Ce que je viens d'écrire ne s'applique pas à tous les codes Python, car il y a plein de cas où, pour des raisons de performance, on passe par des bibliothèques qui obligent d'écrire du code faiblement typé, par exemple numpy.
Remarque 2 : Ce que je viens d'écrire serait overkill pour de simples API CRUD. Plus on a de la logique métier complexe, plus renforcer le typage est bénéfique.
3  1 
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 01/06/2024 à 5:23
Alors que la bonne approche dans ce cas précis est d'avoir deux méthodes publiques set_task_deadline et set_payment_deadline, et une méthode privée _set_deadline.
2  2