définition de classe et implémentation en C# vs C++

Question

Avec C++, je peux avoir une définition de classe dans un fichier d'en-tête, et avoir plusieurs fichiers d'implémentation en incluant le fichier d'en-tête. Avec C#, il semble qu'il n'y ait pas de tel fichier d'en-tête, car une classe devrait contenir à la fois la définition/l'implémentation.

Je me demande si le nombre de lignes peut être très grand, car on ne peut pas séparer la classe en plusieurs fichiers. Ai-je raison? Je veux dire, dans certains cas, on ne peut pas changer la conception de classe pour avoir des classes plus petites. Dans ce cas, existe-t-il un moyen de résoudre ce problème?

Answer 1

Vous pouvez séparer une classe en plusieurs fichiers en utilisant le mot-clé partielle

public partial class ClassNameHere 
{ 
} 

Answer 2

Il est possible de diviser la définition d'une classe ou d'une struct ou une interface sur deux ou plusieurs fichiers source en utilisant le mot-clé partielle modificateur Link to msdn with the partial class

Answer 3

Utilise une classe partielle comme suggère @sparks, ou divisée en plusieurs classes. C'est une bonne règle empirique, si vous ne pouvez pas adapter un cours à quelques pages, c'est assez compliqué à casser.

Answer 4

Les classes partielles ne vous donnent que beaucoup. Il n'y a toujours aucun moyen, à ma connaissance, de séparer votre définition de classe de la mise en œuvre, de sorte que chacun existe dans un fichier séparé. Donc, si vous aimez développer sur la base d'un paradigme de besoin de savoir, vous êtes en quelque sorte coincé. Fondamentalement, il ya trois niveaux, un développeur peut travailler à ...

1) Possède tout le code et a accès à, et maintient tout cela.

2) souhaite utiliser des classes de base utiles qui peuvent faire partie d'un framework, ou peut être juste une classe utile avec certaines méthodes virtuelles, etc, et souhaite étendre, ou ré-implémenter une base virtuelle méthodes d'intérêt de classe. Maintenant, le développeur ne devrait pas avoir besoin d'aller voir le code dans la classe de base afin de comprendre les choses au niveau fonctionnel. Si vous comprenez le travail d'une fonction, c'est les paramètres d'entrée et de sortie, il n'y a pas besoin d'aller et de rayer le code source. Si vous pensez qu'il y a un bug, ou qu'une optimisation est nécessaire, référez-vous au développeur de 1) qui possède et maintient le code de base. Bien sûr, rien ne dit que 1) et 2) ne peuvent pas être associés au même développeur, auquel cas nous n'avons aucun problème. En fait, c'est plus souvent le cas que je soupçonne. Néanmoins, il est toujours bon de garder les choses bien séparées en fonction du niveau auquel vous travaillez.

3) Un développeur doit utiliser un DLL objet/composant déjà emballé/scellé, ce qui expose les interfaces pertinentes.

Dans le contexte de C#, 1) et 3) n'ont aucun problème. Avec 2) je crois qu'il n'y a aucun moyen de contourner cela (à moins que vous ne passiez d'exposer des méthodes de base virtuelles à exposer des méthodes d'interface qui peuvent être réimplémentées dans un composant possédant la classe de base potentielle). Si je veux jeter un oeil à une définition de classe pour parcourir les méthodes, les fonctions d'échafaudage, etc., je dois aussi regarder beaucoup de code source, ce qui m'empêche de me concentrer sur ce que j'essaie de faire. .

Bien sûr, s'il existe une documentation de définition de classe externe à celle que nous faisons normalement (en-têtes et fichiers source), je dois admettre que dans le contexte de 2), il n'y a aucune raison fichier de définition pour acquérir des connaissances fonctionnelles.Alors peut-être que Tom a créé C#, et a décidé de mélanger la définition de classe avec l'implémentation pour encourager les développeurs à avoir des documents externes pour leurs définitions de classe et des interfaces qui font cruellement défaut dans la plupart des entreprises informatiques.