Le principe DRY en C# : Pourquoi la duplication de code nuit à votre base de code - Expliqué par Derek Comartin

Définition du principe DRY

Au début de la vidéo, Derek présente le contexte auquel sont confrontés de nombreux développeurs : un système difficile à modifier, un enchevêtrement de code répété et de logique redondante.

Il présente le principe DRY en C# comme une stratégie visant à réduire la répétition du code, mais prévient qu'il est souvent mal interprété. Comme l'explique Derek à 0:28 :

"Lorsque la méthode DRY est appliquée avec succès, une modification d'un seul élément du système ne nécessite pas la modification d'autres éléments logiquement non liés."

Cette distinction est essentielle. Le principe DRY vise non seulement à éviter la duplication du code, mais aussi à promouvoir la séparation des préoccupations et la réutilisation correcte du code, ce qui permet d'obtenir un code sec et facile à maintenir, plus facile à tester et à remanier.

Exemple pratique : Conversion de distance

Pour rendre les choses tangibles, Derek propose un exemple simple en C#. Il rédige deux méthodes :

• Distance d'expédition

• Distance de péage

Chacun calcule les distances en miles, puis les convertit en kilomètres - en utilisant la même logique dans les deux méthodes. Il s'agit d'une duplication de code classique.

Au lieu d'avoir le même morceau de code à plusieurs endroits, Derek montre comment vous pourriez extraire la logique de conversion dans une méthode privée - MilesToKilometers() - une façon basique mais efficace de refactoriser le code pour la réutilisation.

Il illustre cela en utilisant la structure typique d'une application console : une classe Program avec un void statique Main. C'est le genre de structure que de nombreux développeurs utilisent lorsqu'ils testent la logique ou expérimentent un nouveau scénario d'entrée utilisateur comme public int age, string username, string password, etc.

DRY vs. surcouplage

Si l'abstraction de la logique dans une méthode réutilisable ou une classe distincte semble idéale, Derek invite à la prudence. L'utilisation excessive de la méthode DRY, en particulier pour l'ensemble d'une application, peut conduire à des niveaux de couplage dangereux.

Par exemple, si vous placez la logique de conversion dans un utilitaire partagé utilisé par plusieurs projets, et que vous modifiez ultérieurement son comportement d'arrondi ou sa précision décimale, le changement pourrait affecter de manière inattendue de nombreux domaines. Comme le dit Derek à 2:31 :

Les clients attendent-ils deux décimales ? Que se passe-t-il si nous le remplaçons par zéro ?"

Il s'agit d'une préoccupation transversale - logique réutilisée par de nombreuses parties du système - qui illustre le risque d'une centralisation trop précoce ou sans limites claires.

Les conseils de Derek font écho au principe de responsabilité unique et au principe d'inversion de dépendance, deux autres principes SOLID essentiels pour que votre code reste adaptable et modulaire.

Code Bloat from DRY Gone Wrong (Le gonflement du code à cause de la méthode DRY)

Un autre problème lié à l'utilisation abusive de la méthode DRY est le gonflement du code, où le fait de vouloir tout abstraire conduit à des classes utilitaires surchargées ou à des méthodes trop génériques. Derek prévient qu'une logique trop sèche peut faire plus de mal que de bien, en particulier dans les grands systèmes où les corrections de bogues dans un domaine peuvent en briser d'autres en raison de dépendances partagées.

La clé, selon Derek, est de savoir quand ne pas partager le code - en particulier s'il en résulte des modules étroitement couplés. DRY n'est pas une règle ; il s'agit d'une ligne directrice qui doit être utilisée dans son contexte.

DRY appliqué aux entités : Une recette pour la complexité

Derek identifie une tendance courante chez les développeurs : organiser des systèmes entièrement autour d'entités telles que Truck, Order, Driver et Shipment. Bien qu'il soit tentant de réutiliser la même classe ou le même objet dans différentes méthodes, cela conduit souvent à des concepts répétitifs et à un couplage indésirable.

Il affirme que les capacités commerciales - et pas seulement les structures de données - doivent être à l'origine de l'architecture. Par exemple, "expédier une commande" n'est pas la même chose que "décrocher une remorque", même s'il s'agit des mêmes entités.

À 4:45, Derek explique :

"Une entité singulière dans votre système n'a pas besoin d'être une représentation de plusieurs concepts."

Cela met en lumière une idée architecturale plus profonde : des entités portant le même nom (véhicule, remorque) peuvent représenter des responsabilités différentes dans des flux de travail différents. L'utilisation interchangeable de ces outils est source de confusion et associe étroitement des logiques d'entreprise sans lien entre elles.

DRY et capacités commerciales

Pour résoudre ce problème, Derek présente l'architecture en tranches verticales (VSA), un modèle qui structure les applications autour des capacités commerciales plutôt que des couches. Chaque "tranche" comprend tout ce qui est nécessaire pour une action ou un cas d'utilisation spécifique - de la requête à la base de données - encapsulé et autonome.

Il souligne que le code DRY est bon à l'intérieur d'une tranche - à l'intérieur d'un seul emplacement - mais que l'application de DRY à travers les tranches peut conduire à des dépendances enchevêtrées. À 6:44, il ajoute :

"Il s'agit simplement de réduire le couplage, d'augmenter la cohésion... et l'un des moyens d'y parvenir est de ne pas répéter les concepts à l'intérieur d'une limite"

Ce mode de pensée axé sur les limites vous offre une grande flexibilité. Vous pouvez avoir un modèle de domaine complet dans une tranche et un modèle de données léger dans une autre. Il s'agit de répondre aux besoins de la tranche - une approche pragmatique alignée sur la philosophie de The Pragmatic Programmer (Le programmeur pragmatique).

Conclusion

Derek conclut en recadrant DRY comme un outil et non comme une loi. Comme il le dit à 7:00 :

"Il s'agit simplement de comprendre comment vous l'appliquez. Si vous l'appliquez de manière intensive, vous avez potentiellement plus de couplage."

Avant d'extraire la logique de validation, la chaîne de connexion ou de convertir le code répétitif en une méthode distincte, demandez-vous si cela rendra l'ensemble de votre base de code plus facile à maintenir ou simplement plus difficile à modifier.

Conclusion

La décomposition par Derek Comartin du principe DRY en C# montre comment une règle apparemment simple peut se retourner contre elle lorsqu'elle est appliquée sans nuance. En présentant des exemples de code, en discutant de scénarios pratiques et en mettant l'accent sur les principes de conception des logiciels, il révèle l'équilibre nécessaire entre la réutilisabilité et la modularité.

Pour améliorer considérablement votre processus de développement, n'oubliez pas :

• Utilisez la méthode DRY pour remanier le code redondant à l'intérieur d'une limite claire.

• Ne séparez pas les entités qui ont des objectifs commerciaux différents.

• Respectez le contexte lorsque vous centralisez la logique, en particulier dans plusieurs lieux ou projets.

• Tenez compte des tests unitaires et de la manière dont l'injection de dépendances peut affecter le code partagé.

En appliquant ces leçons, vous écrirez un code C# plus efficace, plus modulaire et plus facile à maintenir, et vous éviterez de transformer votre base de code en un nid à rats de logique dupliquée et de dépendances enchevêtrées.

Vous pouvez regarder l'intégralité de la vidéo de Derek Martin pour en savoir plus sur chaîne YouTube de CodeOpinion.