Est-ce une mauvaise pratique d'avoir plusieurs classes dans le même fichier?
J'avais l'habitude d'avoir une classe pour un fichier. Par exemple car.cs a la classe car. Mais comme je programme plus de classes, je voudrais les ajouter au même fichier. Par exemple car.cs a la classe car et la classe door, etc.
Ma question est bonne pour Java, C #, PHP ou tout autre langage de programmation. Dois-je essayer de ne pas avoir plusieurs classes dans le même fichier ou est-ce correct?
Je pense que vous devriez essayer de garder votre code à 1 classe par fichier.
Je suggère cela car il sera plus facile de retrouver votre classe plus tard. En outre, cela fonctionnera mieux avec votre système de contrôle de code source (si un fichier change, alors 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 être laissées à l'intérieur du même fichier. Les rôles des classes internes sont fortement liés aux classes externes, donc les placer dans le même fichier est très bien.
En Java, une classe public par fichier est la façon dont le langage fonctionne. Un groupe de fichiers Java peuvent être collectés 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 package Python est un répertoire, tout comme un package Java.
Cela donne Python un niveau supplémentaire de regroupement entre classe et package.
Il n'y a pas de bonne réponse qui soit indépendante de la langue. Cela varie selon 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<Customer> { /* whatever */ }
La meilleure règle est de conserver une classe par fichier, sauf lorsque cela commence à rendre les choses plus difficiles plutôt que plus faciles. Étant donné que la recherche dans les fichiers de Visual Studio est si efficace, vous n'aurez probablement pas à passer beaucoup de temps à parcourir la structure des fichiers de toute façon.
Non, je ne pense pas que ce soit une mauvaise pratique. Ce que je veux dire par là, c'est qu'en général, 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 vaut mieux 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 un fichier séparé pour chaque classe de deux lignes? 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 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 wtf j'ai défini le type x.
Alors maintenant, ma règle personnelle est que chaque type individuel (sauf peut-être pour les classes enfants, par lequel signifie une classe à l'intérieur d'une classe, pas une classe héritée) obtient son propre fichier.
Si vous travaillez en équipe, le fait de 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 changent le même fichier en même temps). Je pense que cela facilite également la recherche du code que vous recherchez.
La règle que je respecte toujours est d'en avoir un principale dans un fichier du même nom. Je peux ou non inclure des classes d'assistance dans ce fichier en fonction de leur couplage avec la classe principale du fichier. Les classes de support sont-elles autonomes ou sont-elles utiles seules? 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 du 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 d'être seul.
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 Car si vous avez une classe Car.cs. Où rechercheriez-vous la classe Widget si Widget.cs n'existe pas? Est-ce un widget voiture? Est-ce un widget moteur? Oh, c'est peut-être un widget bagel.
Le niquement 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; vous libérer de la structure physique des fichiers 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 dossier, soyez mon invité. Impossible de le faire avec des classes publiques dans Java cependant;)
Puisque votre IDE vous fournit une fonctionnalité "Navigate to" et vous avez un certain contrôle sur namespacing au sein de vos classes, les avantages ci-dessous d'avoir plusieurs classes dans le même fichier en valent la peine pour moi.
Cours Parent - Enfant
Dans de nombreux cas, je trouve très utile d'avoir des classes héritées dans leur fichier de classe Base.
Il est alors assez facile de voir quelles propriétés et méthodes votre classe enfant hérite et le fichier fournit un aperçu plus rapide de la fonctionnalité globale.
Public: Small - Helper - DTO Classes
Lorsque vous avez besoin de plusieurs classes plain et small pour une fonctionnalité spécifique je trouve assez redondant d'avoir un fichier avec toutes les références et inclut pour seulement a 4-8 Liner class .....
Navigation dans le code est également plus facile en faisant simplement défiler un fichier au lieu de basculer entre 10 fichiers ... Il est également plus facile de refactoriser lorsque vous devez modifier une seule référence au lieu de 10. ....
Globalement, briser la règle de fer de 1 classe par fichier fournit un peu liberté pour organiser votre code.
Ce qui se passe alors dépend vraiment de votre IDE, de votre langue, de votre communication en équipe et de vos capacités d'organisation.
Mais si vous voulez cette liberté, pourquoi la sacrifier pour une règle de fer?
Comme c'est souvent le cas en 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 en fonctionnalités?
Il ne serait pas hors de propos qu'un framework web fournisse un fichier widgets à usage général quel que soit le fichier contenant BaseWidget, TextWidget, CharWidget, etc.
Un utilisateur du framework ne serait pas hors de propos pour définir un fichier more_widgets pour contenir les widgets supplémentaires qu'il dérive des widgets du framework pour leur espace de domaine spécifique.
Lorsque les classes sont orthogonales et n'ont rien à voir entre elles, 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 CarParts et RobotParts serait insensé ... il n'y a probablement pas beaucoup de relation entre la commande de pièces de rechange pour la maintenance et les pièces que l'usine fabrique. Une telle jointure 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 limiter vos choix par une règle de base. Des règles empiriques sont créées pour une première analyse 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 devez 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 étroite 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.
En règle générale, une classe/un fichier est le chemin à parcourir. Cependant, je garde souvent plusieurs définitions d'interface dans un seul fichier. Plusieurs classes dans un seul fichier? Seulement s'ils sont très étroitement liés d'une manière ou d'une autre, et très petits (<5 méthodes et membres)
La réponse Smalltalk est: vous ne devriez pas avoir de fichiers (pour la programmation). Ils rendent le versioning et la navigation pénibles.
Une classe par fichier est plus simple à gérer et beaucoup plus claire pour quiconque regarde votre code. Il est également obligatoire ou très restreint dans certaines langues.
Dans 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.