Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
classes et fichiers
Bonjour,
L'univers du .Net m'étant relativement étranger, j'en connais assez peu les bonnes pratiques. Par exemple, si j'ai une petite classe qui contient 2 variables membres et un constructeur simple, conseillez-vous de créer un nouveau fichier MaMicroClasse.cs?
En général on fait un fichier par classe.
Oui. Parce que rien ne dit que tu n'auras jamais besoin d'ajouter, plus de variables, apporter des modifications et j'en passe.En général on fait un fichier par classe.
De plus, ça permet de voir explicitement,(de mon point de vue) très rapidement, à quoi on a affaire comme objet.
Ah ! Pour moi un fichier par classe est un exemple de mauvaise pratique. Et je peux invoquer de grands noms comme Robert Martin et son Clean Code à mes côtés pour défendre cette vision.
Le problème est simple : si je cherche une classe par son nom, j'ai des quantités de moyens pour ça, depuis le "go to definition" jusqu'à "ctrl + virgule" en passant par la Class View ou l'Object Browser. Je n'ai donc pas besoin d'avoir un fichier par classe, ça n'apporte aucune valeur ajoutée. Au contraire, cela introduit de la pollution visuelle dans l'explorateur de solution et rend difficile la lecture du projet et alourdit son utilisation au quotidien.
Pour moi un fichier est une structure hiérarchique au même titre que la classe, la méthode, etc. C'est donc le niveau au-dessus de la classe et il permet si besoin de montrer l'articulation de certaines classes entre elles. Un fichier peut donc contenir toutes les petites variantes d'une classe de base, ou aussi les quelques types intermédiaires qui participent d'un même traitement. L'idée est qu'en ouvrant la solution on voit quelque chose qui ressemble à ce qu'on attendait a priori, et que les objets intermédiaires, similaires ou connexes soient rassemblés dans un même fichier. Client.cs contiendra Client, ClientManager, ListOfClient, etc. List contiendra List et ListEnumerator. Etcétéra. Un fichier représente davantage un concept
Enfin cela ouvre un avantage non-négligeable : découpler le nom du fichier du nom exact de la classe. Ainsi il peut être intéressant d'utiliser un pluriel s'il y a plusieurs implémentations (DataProviders.cs). Ou de numéroter les fichiers selon leur ordre logique d'utilisation (0.Initializers.cs, 1.Processes.cs, etc). Et réciproquement on peut nommer librement la classe sans se soucier de l'ordre de ce nom dans l'explorateur de solution.
Il est vrai que dans beaucoup de langage c'est une bonne pratique. Il est vrai aussi qu'avec Visual Studio tu as beaucoup d'outils permettant de retrouver des entités (class, enum, etc.) assez facilement.En général on fait un fichier par classe.
Pour ma part, et ça n'engage que moi, j'ai avoir les choses bien clair. Je vais regrouper des modules par project, des couches par solution (Ici dans le cadre de petit projet c'est regroupé), des répertoires par concepts et de fichier par nom de class principale, sachant qu'il peut y avoir ce que je vais appeler les "Nested" c'est à dire toutes les entités qui concerne uniquement ta class.
Des fois il arrive aussi de déclarer les enum ou les struct dans ce même fichier.
Par contre un autre contre exemple d'un fichier par class en .NET et tu ne trouveras pas ça ailleurs (à ma connaissance) se sont les "Partial Class", cela va te permettre d'écrire ta class dans plusieurs fichiers. C'est ce principe qui est utilisé pour développé des GUI via le designer. Toi tu codes dans un fichier MyForm.cs et le designer (que tu vas utiliser pour mettre ne place tes composants de manière graphique) va écrire dans le fichier MyForm.Designer.cs, mais une fois compilé c'est une et une seule class.
En faite pour répondre à ta question, je pense que ça vient plus d'un consensus de projet (entre les acteurs du(es) projet(s)), ou vous allez définir le code style que de règle que tout le monde doit suivre à la règle. Et si tu es tout seul et bien fait comme il te plaît
Cela fait 5 ans que je développe en C# et je commence à savoir une façon de structure les choses (comment je fait mes solutions, mes projets, mes répertoires, mes class, mes variables, etc.) et ce n'est pas une règle copié telle quel mais plus une adaptation de plusieurs règles. Une bonne qualité est de savoir s'adapter aux consensus qui sont définis au sein des projets
+1Envoyé par DonQuiche
Découper un fichier par classe est une très mauvaise pratique qui ne sert qu'à embrouiller les choses et à se retrouver avec tas de using pour exprimer un seul concept (Robert C. Martin à changé ma vie)
J'irai même plus loin en disant que plusieurs concepts peuvent faire partie d'une même idée générale (j'espère que c'est assez clair car j'avoue que c'est assez clair dans ma tête mais ça peut paraitre obscure). Ces concepts peuvent être regroupés dans un namespace particulier.
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
Chacun fait comme il veut mais surtout selon son bon sens. Certains préfèrent un fichier par classe (voire plusieurs fichiers par classe avec le mot clé partial), d'autres préfèrent combiner plusieurs classes dans le même fichier. C'est pour cela que j'avais commencé ma phrase par "en général" (puisque c'est ce que je vois le plus souvent).
Il y a de nombreux débat sur la question. Par exemple :
http://stackoverflow.com/questions/2...le-rule-in-net
http://programmers.stackexchange.com...class-definiti
L'idée générale est qu'il faut faire ce qui te semble le plus adapté à ton cas (i.e. ce qui t'aidera à t'y retrouver facilement dans tes sources et à être le plus efficace)
Répondre avec citation
Partager