Le fait d'avoir beaucoup d'instructions d'utilisation / d'importation indique-t-il une mauvaise conception ou une mauvaise odeur de code?

En règle générale, je vois quelques instructions using en haut du fichier de classe. Exemple:

using System.Collections.Generic;
using System.IO;
using System.Xml.Linq;

Mais dans un projet sur lequel je travaille, à plusieurs reprises, je vois 20 utilisations / importations ou plus dans un fichier de classe. Est-ce une mauvaise conception? Il semble que les classes conçues pour faire une chose ne devraient s'appuyer que sur quelques composants.

programming-practices

— Jon Raynor
source

Visual Studio a une option pour supprimer les usinginstructions inutilisées . Vous voudrez peut-être voir combien de ces 20 sont réellement utilisés.

— Dan Pichelman

@Dan -Ils sont tous utilisés car j'ai utilisé ReSharper pour éliminer ceux qui ne sont pas utilisés.

— Jon Raynor

Avez-vous essayé d'ajouter un IoC, de convertir en injection de constructeur et / ou de convertir certains points d'intégration en lambdas en ligne pour voir si cela réduira le nombre d' usinginstructions sans avoir à augmenter le nombre de classes? Gardez à l'esprit que l'augmentation du nombre de classes ou de fichiers source augmentera la surcharge de gestion du code source.

— rwong

L'IoC cache simplement le problème.

— Telastyn

Certaines de ces choses font presque simplement partie du langage et du style de programmation qu'il encourage, comme Collections.Generic et LINQ, donc je ne m'inquiéterais pas nécessairement de celles-ci. Je concentrerais probablement mon attention sur les autres. La plupart des classes ne devraient probablement pas avoir besoin de faire IO directement, donc, peut-être que si cela se trouve partout, il y a une confusion de responsabilités ou une mauvaise stratification, mais cela dépend de l'application.

— Erik Eidt

Réponses:

Cela peut indiquer un mauvais design, oui. Il se peut que la classe que vous regardez fasse trop de choses, mais cela peut également signifier que les espaces de noms que vous importez sont vraiment plus couplés que ne le laisse entendre la séparation des espaces de noms. Cela peut être dû à une ingénierie excessive ou à une abstraction excessive, mais il peut également s'agir simplement d'une conception qui ne correspond pas bien à l'utilisation.

Cela dit, c'est une odeur - parfois cela vous mène à quelque chose de mauvais, et parfois c'est juste une fausse alarme.

— Telastyn
source

Je pense que la véritable "odeur de code" serait si les espaces de noms importés sont tous, ou pour la plupart, extrêmement différents dans leur objectif. Pour être honnête, j'ai rarement eu plus de 6 à 8 usingdans un seul fichier C #.

— Greg Burghardt

Je voudrais vous donner un deuxième +1 si je le pouvais, juste pour utiliser correctement le terme "odeur de code"!

— Jörg W Mittag

! @Greg - Je suis d'accord, généralement les "utilisations" sont liées. Je pense que dans ce cas, c'est un cas d'abstraction car environ 15-20 des "utilisations" proviennent des espaces de noms des applications et le reste du framework .net.

— Jon Raynor

Une classe ne doit être ni plus grande ni plus petite que ce qui est nécessaire pour fournir une fonction voulue.

Dans une application, j'ai une classe de chiffrement qui a un seul travail: chiffrer les données. Entre la fonctionnalité de base, la journalisation et la gestion des exceptions, l'environnement nécessite 11 importations distinctes d'espace de noms pour effectuer ce travail.

Il m'est difficile de me dire «minimiser les importations». Ou pour juger du succès de ma classe uniquement en comptant le nombre d'espaces de noms importés. Je ne peux pas utiliser cela à juste titre, isolément, comme une indication du succès d'une classe. Pour moi, les «importations» sont le moyen de parvenir à la fin de la classe. Si le travail de la classe est bien défini, tout le reste du système de soutien, y compris les importations, prendra soin de lui-même.

— paulstgeorge
source