Est-ce une mauvaise pratique d’avoir plusieurs classes dans le même fichier?

Je pense que vous devriez essayer de garder votre code à 1 classe par fichier.

Je suggère cela car il sera plus facile de trouver votre classe plus tard. De plus, cela fonctionnera mieux avec votre système de contrôle de code source (si un fichier change, vous savez qu’une classe particulière a changé).

La seule fois où je pense qu’il est correct d’utiliser plus d’une classe par fichier, c’est lorsque vous utilisez des classes internes … mais les classes internes sont à l’intérieur d’une autre classe et peuvent donc restr dans le même fichier. Les rôles des classes internes sont étroitement liés aux classes externes, donc leur classement dans le même fichier est correct.

En Java, une classe publique par fichier correspond au fonctionnement du langage. Un groupe de fichiers Java peut être collecté dans un package.

En Python, cependant, les fichiers sont des “modules” et comportent généralement un certain nombre de classes étroitement liées. Un package Python est un répertoire, tout comme un package Java.

Cela donne à Python un niveau de regroupement supplémentaire entre la classe et le package.

Il n’y a pas une seule bonne réponse qui soit indépendante de la langue. Cela varie avec la langue.

Une classe par fichier est une bonne règle, mais il convient de faire quelques exceptions. Par exemple, si je travaille dans un projet où la plupart des classes ont des types de collection associés, je garde souvent la classe et sa collection dans le même fichier, par exemple:

public class Customer { /* whatever */ } public class CustomerCollection : List { /* whatever */ } 

La meilleure règle à suivre est de garder une classe par fichier, sauf lorsque cela commence à rendre les choses plus difficiles plutôt que plus faciles. Étant donné que Find in Files de Visual Studio est si efficace, vous ne passerez probablement pas beaucoup de temps à parcourir la structure des fichiers.

Non, je ne pense pas que ce soit une mauvaise pratique. Ce que je veux dire par là, c’est en général qu’il vaut mieux avoir un fichier séparé par classe, mais il y a certainement de bons cas d’exception où il est préférable d’avoir un tas de classes dans un seul fichier. Un bon exemple de ceci est un groupe de classes Exception, si vous en avez quelques dizaines pour un groupe donné, est-il vraiment judicieux de séparer un fichier séparé pour chaque classe de liner? Je ne dirais pas. Dans ce cas, avoir un groupe d’exceptions dans une classe est beaucoup moins lourd et simple à mon humble avis.

J’ai constaté que chaque fois que j’essaie de combiner plusieurs types dans un seul fichier, je finis toujours par revenir en arrière et les séparer simplement parce que cela les rend plus faciles à trouver. Chaque fois que je combine, il y a toujours un moment où j’essaie de comprendre le type x défini par wtf.

Donc maintenant, ma règle personnelle est que chaque type individuel (sauf peut-être pour les classes enfants, par lequel une classe dans une classe, pas une classe héritée) obtient son propre fichier.

Si vous travaillez en équipe, conserver les classes dans des fichiers séparés facilite le contrôle de la source et réduit les risques de conflits (plusieurs développeurs modifiant le même fichier en même temps). Je pense que cela facilite également la recherche du code que vous recherchez.

Cela peut être mauvais du sharepoint vue du développement futur et de la maintenabilité. Il est beaucoup plus facile de se rappeler où se trouve la classe Car si vous avez une classe Car.cs. Où recherchez-vous la classe Widget si Widget.cs n’existe pas? Est-ce un widget de voiture? Est-ce un widget de moteur? Oh peut-être que c’est un widget bagel.

La règle que je passe toujours est d’avoir une classe principale dans un fichier du même nom. Je peux ou non inclure des classes d’assistance dans ce fichier, en fonction de la manière dont elles sont couplées avec la classe principale du fichier. Les classes de support sont-elles autonomes ou sont-elles utiles par elles-mêmes? Par exemple, si une méthode dans une classe nécessite une comparaison spéciale pour le sorting de certains objects, cela ne me dérange pas un peu de regrouper la classe de foncteur de comparaison dans le même fichier que la méthode qui l’utilise. Je ne m’attendrais pas à l’utiliser ailleurs et cela n’a pas de sens pour elle.

Le seul moment où je considère les emplacements de fichiers, c’est quand je dois créer de nouvelles classes. Sinon, je ne navigue jamais par structure de fichier. J’utilise “aller en classe” ou “aller à la définition”.

Je sais que c’est un peu un problème de formation; se libérer de la structure physique des fichiers de projets nécessite de la pratique. C’est très gratifiant cependant;)

Si ça fait du bien de les mettre dans le même fichier, sois mon invité. Je ne peux pas le faire avec des cours publics en Java cependant;)

Étant donné que votre IDE vous offre une fonctionnalité ” Naviguer vers ” et que vous avez un certain contrôle sur l’ espace de noms au sein de vos classes, les avantages ci-dessous en ont plusieurs.

Parent – Classes Enfant

Dans de nombreux cas, je trouve très utile d’avoir des classes héritées dans leur fichier de classe de base.

Il est alors très facile de voir quelles propriétés et méthodes votre classe enfant hérite et le fichier fournit une vue d’ensemble plus rapide de la fonctionnalité globale.

Public: Small – Helper – Classes DTO

Lorsque vous avez besoin de plusieurs classes simples et petites pour une fonctionnalité spécifique, je trouve très redondant d’avoir un fichier contenant toutes les références et qui inclut seulement une classe 4-8 Liner …..

La navigation par code est également plus simple, il suffit de faire défiler un fichier au lieu de passer de 10 fichiers à une autre.

En règle générale, la violation de la règle de fer de 1 classe par fichier offre une liberté supplémentaire pour organiser votre code.

Qu’est-ce qui se passe alors, dépend vraiment de votre IDE, langue, communication d’équipe et compétences d’organisation.

Mais si vous voulez cette liberté, pourquoi la sacrifier pour une règle de fer?

En règle générale, une classe / un fichier est la voie à suivre. Je garde souvent plusieurs définitions d’interface dans un seul fichier. Plusieurs classes dans un fichier? Seulement si elles sont très étroitement liées et très petites (<5 méthodes et membres)

Comme c’est souvent le cas dans la programmation, cela dépend beaucoup de la situation.

Par exemple, quelle est la cohésion des classes en question? Sont-ils étroitement couplés? Sont-ils complètement orthogonaux? Sont-ils liés dans la fonctionnalité?

Il ne serait pas hors de propos qu’un framework Web fournisse un fichier widgets.whatever contenant des bases de données, TextWidget, CharWidget, etc.

Un utilisateur du framework ne serait pas en décalage dans la définition d’un fichier more_widgets pour contenir les widgets supplémentaires qu’ils dérivent des widgets du framework pour leur espace de domaine spécifique.

Lorsque les classes sont orthogonales et n’ont rien à voir les unes avec les autres, le regroupement en un seul fichier serait effectivement artificiel. Supposons une application pour gérer une usine robotique qui construit des voitures. Un fichier appelé pièces contenant CarParts et RobotParts serait dépourvu de sens… la relation entre la commande de pièces de rechange pour la maintenance et les pièces fabriquées par l’usine est peu probable. Une telle jointure n’appendait aucune information ou connaissance sur le système que vous concevez.

Peut-être la meilleure règle de base est de ne pas limiter vos choix par une règle de base. Les règles empiriques sont créées pour une parsing de première coupe ou pour limiter les choix de ceux qui ne sont pas capables de faire de bons choix. Je pense que la plupart des programmeurs aimeraient croire qu’ils sont capables de prendre de bonnes décisions.

Vous devriez vous abstenir de le faire, à moins d’avoir une bonne raison.

Un fichier avec plusieurs petites classes associées peut être plus lisible que plusieurs fichiers. Par exemple, lors de l’utilisation de «classes de cas», pour simuler des types d’union, il existe une relation forte entre chaque classe. L’utilisation du même fichier pour plusieurs classes présente l’avantage de les regrouper visuellement pour le lecteur.

Dans votre cas, une voiture et une porte ne semblent pas du tout liées, et trouver la classe de porte dans le fichier car.cs serait inattendu, alors ne le faites pas.

Une classe par fichier est plus simple à gérer et plus claire pour quiconque regarde votre code. Il est également obligatoire ou très restreint dans certaines langues.

En Java, par exemple, vous ne pouvez pas créer plusieurs classes de niveau supérieur par fichier, elles doivent être dans des fichiers séparés où le nom de classe et le nom de fichier sont identiques.

La réponse Smalltalk est la suivante: vous ne devriez pas avoir de fichiers (pour la programmation). Ils rendent les versions et la navigation douloureuses.