Les classes C# dans des fichiers séparés ?

Question

Chaque classe de mon projet C# devrait-elle avoir son propre fichier (à votre avis) ?

Answer 1

Alors que la politique d'une classe par fichier est strictement appliquée en Java, elle n'est pas requise en C#. Cependant, c'est généralement une bonne idée.

J'enfreins généralement cette règle si j'ai une toute petite classe d'aide qui n'est utilisée que par la classe principale, mais je préfère la faire en tant que classe interne imbriquée pour des raisons de clarté.

Vous pouvez cependant diviser une classe unique en plusieurs fichiers en utilisant le partial mot-clé . Ceci est utile pour séparer votre code du code généré par l'assistant.

Answer 2

Les fichiers sont bon marché, vous ne rendez service à personne en regroupant plusieurs classes en un seul fichier.

Dans Visual Studio, le fait de renommer le fichier dans l'explorateur de solutions renommera la classe et toutes les références à cette classe dans votre projet. Même si vous n'utilisez que rarement cette fonctionnalité, le caractère bon marché des fichiers et la facilité de leur gestion font que l'avantage est infiniment précieux, une fois divisé par son coût.

Answer 3

Comme d'autres l'ont dit, un fichier par type en général - bien que là où d'autres ont fait la distinction public/privé, je dirais simplement "un fichier de haut niveau par type" (ainsi même les types internes de haut niveau obtiennent leurs propres fichiers).

J'ai une exception à cette règle, qui est moins pertinente depuis l'arrivée des types de délégués Func et Action dans .NET 3.5 : si je définis plusieurs types de délégués dans un projet, je les regroupe souvent dans un fichier appelé Delegates.cs.

Il y a aussi d'autres exceptions très occasionnelles - j'ai récemment utilisé des classes partielles pour que plusieurs classes générées automatiquement mettent en œuvre la même interface. Elles définissaient déjà les méthodes appropriées, il suffisait donc d'écrire :

public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {}
public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}

etc. Mettre tous ces éléments dans leurs propres fichiers aurait été un peu stupide.

Une chose à garder à l'esprit dans tout cela : l'utilisation de ReSharper facilite l'accès à vos classes, qu'elles soient dans des fichiers judicieusement nommés ou non. Cela ne veut pas dire que les organiser correctement n'est pas une bonne chose de toute façon ; c'est plus pour renforcer la notion que ReSharper est génial :)

Answer 4

Je pense personnellement que chaque classe devrait être dans son propre fichier, y compris les types imbriqués. Les seules exceptions à cette règle pour moi sont les délégués personnalisés.

La plupart des réponses ont exclu les classes privées de cette règle, mais je pense qu'elles devraient aussi être dans leur propre fichier. Voici un modèle que j'utilise actuellement pour les types imbriqués :

Foo.cs : // Contient uniquement l'implémentation de Foo

public partial class Foo 
{
   // Foo implementation
}

Foo.Bar.cs : // Contient uniquement l'implémentation de Foo.Bar

public partial class Foo
{
  private class Bar
  {
    // Bar implementation
  }
}

Answer 5

Cela dépend. La plupart du temps, je dirais oui, mettez-les dans des fichiers séparés. Mais si j'avais une classe d'aide privée qui ne serait utilisée que par une seule autre classe (comme le nœud ou l'élément d'une liste chaînée), je ne recommanderais pas de les séparer.