Discussion :

[neguib]

Bonjour à toutes et tous

Ma question peut paraître bête ou simpliste à première vue. Cependant, suite à l'utilisation de l'outil Assembly Analyser de SharpDevelop, j'obtiens la remarque suivante:

Eviter d'avoir des espaces de noms avec peu de membres
Description
Un espace de nom doit généralement contenir un minimum de cinq types.
Résolution
Envisagez de fusionner les types de l'espace de nom Blablabla avec un autre espace de nom.

Sur quoi repose cette description "doit généralement" et surtout pourquoi ce minimum chiffrer à 5 :

En vous remerciant, cordialement neguib

[Merlin]

Sur quoi repose cette description "doit généralement" et surtout pourquoi ce minimum chiffrer à 5

J'ai une réponse très ...Nette : ça repose sur rien :-)

En revanche le bon sens indique qu'en "général" un espace de nom doit contenir un "certain nombre" de classes.
Cela tout simplement parce que les namespaces ont été créés pour _regrouper_ les classes et autres déclarations et créer ainsi des hiérarchies claires et pratiques.
Si on créé des espaces de nom qui ne contiennent presque rien, c'est donc la porte ouverte à la multiplication des espaces de nom... ce qui est paradoxal. A la limite extrême et débile, une classe dans un espace de nom... Et là, pouf, le concept de namespace n'a plus d'intérêt.

Dans l'autre sens, un namespace avec 500 classes dedans c'est une hérésie. Il faut découper les espaces en sous espaces, comme on le voit dans le framework par exemple avec System qui débouche sur des sous espaces eux mêmes segmentés etc.

Donc en réalité, c'est la définition même de l'espace de nom qu'il faut comprendre et l'utilité de cet artifce déclaratif.
Un espace de nom qui contient trop "peu" ou "trop" de classes ne respecte pas l'objectif visé.

Mais vouloir "chiffrer" les limites inférieure et supérieure est bien entendu débile, il faut le dire clairement :-)

[Piotrek]

FxCop dispose de la meme regle
Cat:
Avoid having a namespace with a small number of types

Description:
A namespace should generally have more than five types.

http://www.gotdotnet.com/team/libraries/FxCopRules/DesignRules.aspx

J'ai absolument rien trouve sur ce "5 types dans un namespace" sur le net, a mon avis il s'agit d'un chiffre arbitraire designant le "peu" (certains developpeurs peuvent trouver que leur 35 types c'est peu par rapport au framework.Net)

Pourquoi environ 5 types ca serait trop peu? A mon avis c'est juste pour alerter l'utilisateur sur le fait qu'il a potentiellement mal construit sa hierarchie de namespaces en la precisant trop.

Le namespace doit etre un compromis entre la meilleure classification et la meilleure utilisation possible. A trop faire de namespaces trop vides, on rend l'application ou le framework plus difficile d'utilisation.

C'est qu'une supposition bien sur

EDIT: +1 avec Merlin donc

[Maniak]

Tout pareil.

De toute façon, on organise les namespaces par rapport à ce que "veut" le code. Ce qui semble le plus logique.

Si chaque classe a bien *sa* responsabilité et qu'on n'en a pas certaines qui font 50 choses différentes, ça se répartit tout seul. Après, peu importe le nombre de classes dans un namespace. Si c'est le plus clair/logique, c'est bon.

La règle de FxCop dit "should generally". Pas une obligation, plutôt une indication pour faire penser à jeter un oeil sur son organisation de temps en temps.

La version SharpDevelop et son "doit généralement", j'aime moins :)
Mais c'est visiblement une bête traduction de FxCop. "should generally" -> "devrait généralement". C'est déjà un peu moins 'imposé'.
Vive les VF... :)

[neguib]

Je vous remercie tous de vos judicieuses réponses.

Effectivement, je ne voyais pas trop l'intérêt par rapport à la petite appli console que j'avais fait (4 types), de me forcer à trouver le moyen de créer une 5ième classe juste pour ne plus voir le message d'avertissement

Je vous suis reconnaissant pour le temps que vous avez consacré à me repondre