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

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

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

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

Il n'y a pas de bonne réponse qui soit agnostique. Cela varie avec la langue.

Une classe par fichier est une bonne règle, mais il est approprié 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 garderai souvent la classe et sa collection dans le même fichier, par exemple:

public class Customer { /* whatever */ }

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

La meilleure règle de base est de garder une classe par fichier, sauf lorsque cela commence à rendre les choses plus difficiles plutôt que plus faciles. Puisque la recherche de Visual Studio dans les fichiers est si efficace, vous n'aurez probablement pas à passer beaucoup de temps à chercher à travers la structure du fichier de toute façon.

Non, Je ne pense pas que ce soit une mauvaise pratique. Ce que je veux dire par là est en général qu'il est préférable d'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 fichier. Un bon exemple de ceci est un groupe de classes D'Exception, si vous en avez quelques dizaines pour un groupe donné, est-il vraiment logique d'avoir séparé un fichier séparé pour chaque classe de ligne? Je dirais pas. Dans ce cas, avoir un groupe d'exceptions dans un classe est beaucoup moins lourd et simple IMHO.

J'ai trouvé que chaque fois que j'essaie de combiner plusieurs types en 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.

Alors 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, garder 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 changent 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 point de vue du développement futur et de la maintenabilité. Il est beaucoup plus facile de se rappeler où se trouve la classe de voiture si vous avez une voiture.cs de la classe. Où chercheriez-vous la classe Widget si Widget.cs n'existe pas? Est-ce un widget de voiture? Est-ce un widget moteur? Oh peut-être que c'est un widget bagel.

La règle que j'ai toujours par avoir un main classe dans un fichier avec le même nom. Je peux ou non inclure des classes d'aide dans ce fichier en fonction de la manière dont elles sont couplées avec la classe principale du fichier. Sont les classes de soutien autonome, ou sont-ils utiles? Par exemple, si une méthode dans une classe a besoin d'une comparaison spéciale pour trier certains objets, cela ne me dérange pas un peu de regrouper la classe comparison functor dans le même fichier que la méthode qui l'utilise. Je Je ne m'attendrais pas à l'utiliser ailleurs et cela n'a pas de sens pour qu'il soit seul.

Le seulement le temps que je considère les emplacements de fichiers est quand je dois créer de nouvelles classes. Sinon, je ne navigue jamais par structure de fichier. Utilisation de la "classe" ou "aller à la définition".

Je sais que c'est un peu un problème de formation; se libérer de la structure de fichiers physique des 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, soyez mon invité. Je ne peux pas le faire avec des classes publiques en java;)

Puisque votreIDE vous fournit une fonctionnalité "Navigate to " et que vous avez un certain contrôle surnamespacing dans vos classes, les avantages ci-dessous d'avoir plusieurs classes dans le même fichier en valent la peine pour moi.

Classes Parent-Enfant

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

Il est alors assez 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: Classes Small - Helper - Dto

Lorsque vous avez besoin de plusieurs plaine et petit classes fonctionnalités spécifiques je trouve ça assez redondant d'avoir un fichier avec toutes les références et comprend, pour juste un 4-8 Liner classe.....

La navigation par Code est également plus facile à faire défiler sur un fichier au lieu de commutation entre 10 fichiers...Il est également plus facile de refactor lorsque vous devez éditer une seule référence au lieu de 10.....

Globalement, la rupture de la règle de fer de 1 classe par fichier fournit une certaine liberté supplémentaire pour organiser votre code.

Ce qui se passe alors dépend vraiment de votre IDE, de votre langue, de votre Communication D'équipe et de vos compétences en 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 seul fichier est le chemin à parcourir. Je garde souvent plusieurs définitions d'interface dans un fichier, cependant. Plusieurs classes dans un fichier? Seulement si elles sont très étroitement liées en quelque sorte, et très petites (

Comme c'est le cas la plupart du temps en programmation, cela dépend grandement 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 à la fonctionnalité?

Il ne serait pas hors de ligne pour un framework web de fournir un widgets à usage général.quel que soit le fichier contenant BaseWidget, TextWidget, CharWidget, etc.

Un utilisateur du framework ne serait pas hors de ligne dans la définition un fichier more_widgets pour contenir les widgets supplémentaires qu'ils dérivent des widgets 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 en effet artificiel. Supposons une application pour gérer une usine robotique qui construit des voitures. Un fichier appelé pièces contenant des CarParts et RobotParts serait insensé... il est peu probable qu'il y ait beaucoup de relation entre la commande de pièces de rechange pour l'entretien et les pièces que l'usine fabrique. Une telle jonction n'ajouterait aucune information ou connaissance sur le système que vous concevez.

Peut-être que la meilleure règle de base est de ne pas contraindre vos choix par une règle de base. Des règles empiriques sont créées pour une première analyse de coupe, ou pour contraindre 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, sauf si vous avez 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 a 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 voiture.le fichier cs serait inattendu, alors ne le faites pas.

Une classe par fichier est plus simple à maintenir et beaucoup 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 les mêmes.

La réponse de Smalltalk est: vous ne devriez pas avoir de fichiers (pour la programmation). Ils rendent le versioning et la navigation douloureux.