web-dev-qa-db-fra.com

DRY code indépendant, mais presque identique

J'ai du code presque identique, mais utilise des types absolument différents, sans héritage entre eux, sur la variable principale. Plus précisément, j'écris un analyseur avec Roslyn pour C # et VB.NET, avec les types suivants:

Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax

Je me demande si, parce que le code fait la même chose, je devrais le garder comme DRY possible, en se séparant le moins possible en méthodes distinctes (mais identiques à part le type), ou la séparer complètement parce que les deux méthodes ne sont pas liées et que les changements futurs pourraient forcer une version à changer, mais pas l'autre (bien que cela soit peu probable)?

Edit: Un an plus tard, j'ai rencontré ce même problème, et l'équipe de Roslyn m'a aidé à le résoudre: Écrivez une classe de base qui prend des génériques et a un paramètre TAttributeSyntax qui fait le plus du travail. Ensuite, écrivez des classes dérivées avec le strict minimum de données qui nécessitent un type spécifique.

34
user113093

Vous ne faites pas DRY parce que quelqu'un l'a écrit dans un livre quelque part que c'est bien de le faire, vous faites DRY parce qu'il a en fait tangible avantages.

Plus précisément à partir de cette question:

Si vous vous répétez, vous pouvez créer des problèmes de maintenabilité. Si doStuff1-3 ont tous un code structuré de la même manière et que vous résolvez un problème en un, vous pouvez facilement oublier de résoudre le problème ailleurs. De plus, si vous devez ajouter un nouveau cas à gérer, vous pouvez simplement passer différents paramètres dans une seule fonction plutôt que de copier-coller partout.

Cependant, DRY est souvent poussé à l'extrême par des programmeurs intelligents. Parfois, pour ne pas vous répéter, vous devez créer des abstractions si obtuses que vos coéquipiers ne peuvent pas les suivre. Parfois, la structure de deux choses n'est que vaguement similaire mais assez différent. Si doStuff1-4 sont suffisamment différents pour que leur refactorisation pour ne pas se répéter vous oblige à écrire du code non naturel ou à subir des backflips de codage intelligents qui feront que votre équipe vous lorgnera, alors il peut être correct de répéter Je me suis penché en arrière pour ne pas me répéter plusieurs fois de manière non naturelle et j'ai regretté le produit final.

Donc, fondamentalement, ne pensez pas "oh mec, ce code est assez similaire, je devrais peut-être refactoriser pour ne pas me répéter". Pensez "ne refactoring pour rendre cette base de code réutilisation des éléments communs rendre le code plus maintenable ou moins maintenable ? " Ensuite, choisissez celui qui le rend plus maintenable.


Cela étant dit, étant donné SRP et en essayant simplement d'avoir de petites classes flexibles en général, il pourrait être judicieux d'analyser votre code pour pour cette raison , séparez les bits de comportement qui utilisent des types génériques (vous avez dit qu'ils sont identiques autres que type) en petites classes. Ensuite, vous découvrirez que certaines de ces classes sont en fait totalement identiques (pas seulement principalement identiques), puis vous pouvez créer une boîte à outils au cas où vous voulez ajouter Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax.

110
durron597