Combien de classes dois-je mettre dans un fichier? [fermé]

Je suis habitué au modèle Java où vous pouvez avoir une classe publique par fichier. Python n'a pas cette restriction, et je me demande quelle est la meilleure pratique pour organiser des cours.

Un fichier Python est appelé un "module" et c'est une façon d'organiser votre logiciel pour qu'il ait du "sens". Un autre est un répertoire, appelé "package".

Un module est une chose distincte qui peut avoir une ou deux douzaines de classes étroitement liées. L'astuce est qu'un module est quelque chose que vous importerez, et vous avez besoin que cette importation soit parfaitement sensible aux personnes qui liront, maintiendront et étendront votre logiciel.

La règle est la suivante: un module est l'unité de réutilisation .

Vous ne pouvez pas facilement réutiliser une seule classe. Vous devriez pouvoir réutiliser un module sans aucune difficulté. Tout dans votre bibliothèque (et tout ce que vous téléchargez et ajoutez) est soit un module, soit un ensemble de modules.

Par exemple, vous travaillez sur quelque chose qui lit des feuilles de calcul, fait des calculs et charge les résultats dans une base de données. À quoi voulez-vous que votre programme principal ressemble?

from ssReader import Reader
from theCalcs import ACalc, AnotherCalc
from theDB import Loader

def main( sourceFileName ):
    rdr= Reader( sourceFileName )
    c1= ACalc( options )
    c2= AnotherCalc( options )
    ldr= Loader( parameters )
    for myObj in rdr.readAll():
        c1.thisOp( myObj )
        c2.thatOp( myObj )
        ldr.laod( myObj )

Considérez l'importation comme le moyen d'organiser votre code en concepts ou en morceaux. Le nombre exact de classes dans chaque importation n'a pas d'importance. Ce qui importe, c'est l'organisation globale que vous représentez avec vos importdéclarations.

Puisqu'il n'y a pas de limite artificielle, cela dépend vraiment de ce qui est compréhensible. Si vous avez un tas de classes simples assez courtes qui sont logiquement regroupées, jetez-en un tas. Si vous avez de grandes classes complexes ou des classes qui n'ont pas de sens en tant que groupe, choisissez un fichier par classe. Ou choisissez quelque chose entre les deux. Refactorisez à mesure que les choses changent.

Il se trouve que j'aime le modèle Java pour la raison suivante. Placer chaque classe dans un fichier individuel favorise la réutilisation en rendant les classes plus faciles à voir lors de la navigation dans le code source. Si vous avez un groupe de classes regroupées dans un seul fichier, il peut ne pas être évident pour d'autres développeurs qu'il existe des classes qui peuvent être réutilisées simplement en parcourant la structure de répertoires du projet . Ainsi, si vous pensez que votre classe peut éventuellement être réutilisée, je la mettrais dans son propre fichier.

Cela dépend entièrement de la taille du projet, de la longueur des classes, de leur utilisation à partir d'autres fichiers, etc.

Par exemple, j'utilise assez souvent une série de classes pour l'abstraction des données - je peux donc avoir 4 ou 5 classes qui ne peuvent avoir qu'une ligne ( class SomeData: pass).

Ce serait stupide de diviser chacun de ces fichiers en fichiers séparés - mais comme ils peuvent être utilisés à partir de fichiers différents, il data_model.pyserait logique de les mettre tous dans un fichier séparé , donc je peux le fairefrom mypackage.data_model import SomeData, SomeSubData

Si vous avez une classe avec beaucoup de code, peut-être avec certaines fonctions seulement qu'elle utilise, ce serait une bonne idée de diviser cette classe et les fonctions d'assistance dans un fichier séparé.

Vous devez les structurer de manière à ce que vous ne le fassiez from mypackage.database.schema import MyModelpas from mypackage.email.errors import MyDatabaseModel- si l'endroit où vous importez des choses a du sens et que les fichiers ne font pas des dizaines de milliers de lignes, vous les avez organisés correctement.

La documentation des modules Python contient des informations utiles sur l'organisation des packages.

Je me retrouve à diviser les choses lorsque je suis ennuyé par la taille des fichiers et lorsque la structure souhaitable de la parenté commence à émerger naturellement. Souvent, ces deux étapes semblent coïncider.

Cela peut être très ennuyeux si vous divisez les choses trop tôt, car vous commencez à réaliser qu'un ordre de structure totalement différent est nécessaire.

D'un autre côté, lorsqu'un fichier .java ou .py atteint plus de 700 lignes environ, je commence à m'énerver constamment en essayant de me rappeler où se trouve "ce bit particulier".

Avec Python / Jython, la dépendance circulaire des instructions d'importation semble également jouer un rôle: si vous essayez de diviser un trop grand nombre de blocs de construction de base coopérants en fichiers séparés, cette "restriction" / "imperfection" du langage semble vous obliger à regrouper les choses, peut-être d'une manière plutôt sensée.

En ce qui concerne la division en packages, je ne sais pas vraiment, mais je dirais probablement que la même règle d'agacement et d'émergence d'une structure heureuse fonctionne à tous les niveaux de modularité.

Je dirais de mettre autant de classes qu'il est possible de les regrouper logiquement dans ce fichier sans le rendre trop gros et complexe.