Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallLe principe DRY (« Don’t Repeat Yourself ») ne demande pas d’éliminer chaque répétition de code. Il invite à donner une représentation unique et faisant autorité à chaque élément de connaissance ou d’intention du système. Si une même règle doit être modifiée à plusieurs endroits, elle risque de diverger; si deux blocs se ressemblent sans exprimer la même règle, les fusionner peut au contraire compliquer le code.
Ce que DRY veut vraiment dire
Dans The Pragmatic Programmer, David Thomas et Andrew Hunt formulent le principe ainsi : « Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. » Autrement dit, chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité dans le système. Ils précisent que DRY porte sur la duplication de connaissance et d’intention, y compris lorsque la même chose est exprimée de façons différentes. Lire l’extrait officiel consacré à DRY.
As an Amazon Associate I earn from qualifying purchases.
Cette distinction compte : deux portions de code identiques peuvent répondre à des règles métier différentes; inversement, une même règle peut être répétée dans du code, une documentation ou un schéma, sans que les formulations se ressemblent. DRY concerne cette connaissance dupliquée, pas une ressemblance visuelle prise isolément.
Free tools Windows power users keep installed
One-click scans. No signup required.
Comment savoir si une répétition pose problème
Pose-toi la question du changement : si cet aspect du système évolue, faudra-t-il le modifier à plusieurs endroits ou sous plusieurs formes? Si oui, ces représentations peuvent être des copies d’une même connaissance. Une mise à jour oubliée risque alors de laisser des versions contradictoires.
- Même règle, plusieurs occurrences : une règle de validation ou un calcul identique est maintenu séparément dans plusieurs fonctions. Si chaque changement doit les garder synchronisés, une représentation partagée peut être préférable.
- Même apparence, règles différentes : deux blocs se ressemblent aujourd’hui, mais leurs comportements doivent évoluer indépendamment. Les réunir dans une abstraction commune pourrait cacher leur différence et lier des changements qui ne devraient pas l’être.
- Même connaissance, formats différents : une contrainte présente dans la documentation et dans un schéma peut devoir rester cohérente, même si ces deux représentations n’ont pas la même forme.
Le nombre d’occurrences, à lui seul, ne décide pas s’il faut abstraire. Le critère utile est de déterminer si les éléments expriment la même connaissance et doivent évoluer ensemble, plutôt que de compter les lignes ou les ressemblances.
Quand plusieurs représentations sont nécessaires
Il n’est pas toujours possible, ni souhaitable, de n’avoir qu’une forme physique d’une règle. Une contrainte de base de données ou de middleware peut imposer plusieurs représentations. Dans ce cas, l’objectif est de désigner clairement celle qui fait autorité et, lorsque c’est possible, de produire les autres à partir de cette source. Dave Thomas décrit cette approche dans son article pour IEEE Software : « Ideally, you’d be able to automatically generate or produce the nonauthoritative sources from the single authoritative source. » Lire l’article de Dave Thomas.
Rank #2
La question pratique devient alors : quelle représentation est la source de vérité, et lesquelles en sont des dérivées? Si les copies ne peuvent pas être générées automatiquement, il faut au moins savoir qu’elles doivent rester synchronisées et où les mettre à jour.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsUn test simple avant de créer une abstraction
- Identifie la règle : décris en une phrase la connaissance ou l’intention que chaque occurrence exprime.
- Compare leur évolution : si la règle change, ces occurrences doivent-elles toutes changer ensemble?
- Choisis une source faisant autorité : si elles représentent bien la même chose, envisage une fonction, un module ou une autre représentation partagée adaptée au contexte.
- Garde les différences explicites : si les règles peuvent évoluer séparément, conserve des implémentations distinctes plutôt que de les forcer dans une abstraction commune.
Ce test traduit la portée du principe décrite par Thomas et Hunt; ce n’est pas une règle mécanique imposant une abstraction dès qu’un motif apparaît deux fois.
Pourquoi la chasse au copier-coller peut mal tourner
Éliminer toute répétition apparente peut produire des abstractions trop générales, rendre les règles métier moins lisibles ou faire dépendre des comportements distincts d’un même mécanisme. DRY n’est donc pas une consigne de compression du code. Il s’agit de rendre visible où se trouve la connaissance qui fait autorité et d’éviter de maintenir séparément plusieurs versions de la même intention.
Le bénéfice attendu est une cohérence plus claire et une maintenance mieux organisée. Les sources consacrées au principe ne fournissent pas de statistique permettant de lui attribuer un pourcentage garanti de réduction des bogues ou du temps de développement.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Pour approfondir
The Pragmatic Programmer: Your Journey to Mastery, de David Thomas et Andrew Hunt, est disponible dans son édition du 20e anniversaire publiée en septembre 2019. La page de l’éditeur présente une section intitulée « DRY—The Evils of Duplication » et répertorie des formats imprimé et numérique : page officielle de l’édition anniversaire. Pour une autre présentation du principe, Steve Smith lui consacre le chapitre 30 de 97 Things Every Programmer Should Know : aperçu du chapitre chez O’Reilly.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
