Il semble que l'on soustrait beaucoup de logique aux pages Web et que l'on crée des classes "d'assistance". Malheureusement, ces classes sonnent toutes de la même façon, par exemple
ADHelper, (Active Directory) AuthenicationHelper, SharePointHelper
D'autres personnes ont-elles un grand nombre de classes avec cette convention de dénomination?
Je dirais qu'il qualifie comme une odeur de code, mais rappelez-vous que une odeur de code n'est pas nécessairement le sort de la difficulté. C'est quelque chose que vous devriez regarder dans et de décider ensuite si c'est bon.
Ayant dit que, personnellement, je trouve que l'un des noms qui ajoute peu de valeur, et parce qu'il est tellement générique, le type peut facilement devenir un seau de non-liés les méthodes de l'utilitaire. I. e. une classe d'assistance peut se transformer en une Grande Classe, qui est une des communes odeurs de code.
Si possible, je suggère de trouver un nom de type plus proche de ce que les méthodes ne. Bien sûr, cela peut susciter d'autres classes d'assistance, mais aussi longtemps que leurs noms sont utiles, je ne crains pas les chiffres.
Il y a quelques temps je suis tombé sur une classe appelée XmlHelper au cours d'une revue de code. Il avait un certain nombre de méthodes qui, évidemment, tous les avions à faire avec Xml. Cependant, il n'était pas clair à partir du nom de type de ce que les méthodes ont en commun (à part d'être Xml). Il s'est avéré que certaines méthodes ont été mise en forme Xml et d'autres ont été l'analyse de Xml. Donc, IMO, la classe devrait avoir été divisé en deux ou plusieurs parties, avec des noms plus spécifiques.
Comme toujours, ça dépend du contexte.
Lorsque vous travaillez avec votre propre API, je n'hésiterais pas à les considérer comme une odeur de code, car FooHelper indique qu'il opère sur l' Foo, mais le comportement serait le plus susceptible d'appartenir directement sur l' Foo classe.
Toutefois, lorsque vous travaillez avec les APIs existantes (telles que les types de la BCL), vous ne pouvez pas changer la mise en œuvre, de sorte que des méthodes d'extension de devenir l'un des moyens pour remédier aux lacunes dans l'original de l'API. Vous pouvez choisir les noms de ces classes FooHelper comme FooExtension. Il est tout aussi puant (ou pas).
Dépend du contenu réel des cours.
Si une énorme quantité de logique métier / règles métier se trouvent dans les classes d'assistance, alors je dirais oui.
Si les classes ne sont vraiment que des aides qui peuvent être utilisées dans d'autres applications d'entreprise (réutilisation dans le sens absolu du mot - pas copier puis personnaliser), alors je dirais que les aides ne sont pas une odeur de code.
C'est un point intéressant, si un mot devient «passe-partout» dans les noms, alors c'est probablement un peu flippant - si ce n'est pas vraiment une vraie odeur. Peut-être que l'utilisation d'un dossier 'Helper' et ensuite le laisser apparaître dans l'espace de noms conserve son utilisation sans trop utiliser le mot?
Application.Helper.SharePoint
Application.Helper.Authentication
etc
Dans de nombreux cas, j'utilise des classes de fin avec Helper pour les classes statiques contenant des méthodes d'extension. Ne semble pas malodorante pour moi. Vous ne pouvez pas les mettre dans une situation de non-statique de la classe, et la classe elle-même n'a pas d'importance, de sorte Helper est très bien, je pense. Les utilisateurs de cette classe de ne pas voir le nom de la classe de toute façon.
L' .NET Framework fait la même chose (par exemple dans l' LogicalTreeHelper classe de WPF, qui a juste un peu statique (sans extension) méthodes).
Demandez-vous si le code serait mieux si le code dans votre classe d'aide serait remaniée à de "vrais" cours, c'est à dire des objets qui correspondent à votre hiérarchie de classe. Code de a à quelque part, et si vous ne pouvez pas faire sur une classe/objet où il appartient vraiment, comme de simples fonctions d'assistance (d'où "Helper"), vous devriez être bien.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
