Je suis habitué au modèle Java où l'on peut avoir une classe publique par fichier. Python n'a pas cette restriction, et je me demande quelle est la meilleure pratique pour organiser les classes.
Haha, j'aime le "sens" entre guillemets.
Je suis habitué au modèle Java où l'on peut avoir une classe publique par fichier. Python n'a pas cette restriction, et je me demande quelle est la meilleure pratique pour organiser les classes.
Un fichier Python s'appelle un "module" et c'est une façon d'organiser votre logiciel pour qu'il ait du "sens". Un autre moyen 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 allez importer, et vous avez besoin que cette importation soit parfaitement sensée pour les personnes qui vont lire, maintenir et étendre 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 être en mesure de réutiliser un module sans aucune difficulté. Tout ce qui se trouve dans votre bibliothèque (et tout ce que vous téléchargez et ajoutez) est soit un module, soit un paquet de modules.
Par exemple, vous travaillez sur quelque chose qui lit des feuilles de calcul, effectue quelques calculs et charge les résultats dans une base de données. À quoi doit ressembler votre programme principal ?
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 un 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 compte, c'est l'organisation générale que vous donnez à votre code. import
déclarations.
Le sens d'une personne est la folie d'une autre. En général, vous pouvez définir des modules sensés. Dans une grande application, cependant, il y a toujours de multiples dimensions d'analyse et une personne va couper les cheveux en quatre sur le découpage des fonctionnalités d'une autre personne.
Les recommandations ci-dessus sont en accord avec docs.python-guide.org/fr/latest/writing/structure
Comme 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 et courtes qui sont logiquement regroupées, mettez-en quelques-unes. Si vous avez de grandes classes complexes ou des classes qui n'ont pas de sens en tant que groupe, allez-y avec un fichier par classe. Ou choisissez quelque chose entre les deux. Refaites-le au fur et à 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 lorsque l'on parcourt le code source. Si vous avez un tas de classes regroupées dans un seul fichier, il peut ne pas être évident pour d'autres développeurs qu'il y a là des classes qui peuvent être réutilisées en parcourant simplement le fichier structure des répertoires . Ainsi, si vous pensez que votre classe peut éventuellement être réutilisée, je la mettrais dans son propre fichier.
Je suis tout à fait d'accord avec vous. Avoir plusieurs classes publiques dans un seul fichier n'est pas intuitif et rend le code difficile à appréhender, comme si quelqu'un voulait cacher la structure et avait l'impression d'être fait de bric et de broc. Surtout si vous passez de Java à Python.
Cela dépend entièrement de la taille du projet, de la longueur des classes, si elles seront utilisées à partir d'autres fichiers, etc.
Par exemple, j'utilise assez souvent une série de classes pour l'abstraction de données - je peux donc avoir 4 ou 5 classes qui peuvent ne faire qu'une ligne ( class SomeData: pass
).
Il serait stupide de diviser chacun de ces éléments en fichiers distincts - mais comme ils peuvent être utilisés à partir de différents fichiers, les placer tous dans un fichier distinct data_model.py
serait logique, je peux donc faire from mypackage.data_model import SomeData, SomeSubData
Si vous avez une classe contenant beaucoup de code, peut-être avec des fonctions qu'elle seule utilise, ce serait une bonne idée de séparer cette classe et les fonctions d'aide dans un fichier séparé.
Vous devez les structurer de façon à ce que vous from mypackage.database.schema import MyModel
pas from mypackage.email.errors import MyDatabaseModel
- si l'endroit d'où vous importez des choses a un sens, et que les fichiers ne font pas des dizaines de milliers de lignes, vous avez organisé les choses correctement.
El Documentation sur les modules Python contient des informations utiles sur l'organisation des forfaits.
Lien brisé vers la documentation des modules Python. Peut-être Section 6.4 Modules.Packages est le lien prévu maintenant ?
Je me retrouve à diviser les choses lorsque la taille des fichiers m'ennuie et lorsque la structure souhaitable de 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 à vous rendre compte qu'un ordre de structure totalement différent est nécessaire.
D'un autre côté, lorsqu'un fichier .java ou .py dépasse les 700 lignes, je commence à m'ennuyer en essayant constamment de me rappeler où se trouve "ce bit particulier".
Avec Python/Jython, la dépendance circulaire des déclarations d'importation semble également jouer un rôle : si vous essayez de répartir un trop grand nombre d'éléments de base coopérants dans des fichiers séparés, cette "restriction"/"imperfection" du langage semble vous obliger à regrouper les choses, peut-être d'une manière plutôt judicieuse.
Quant à la division en paquets, je ne sais pas vraiment, mais je dirais que la même règle d'ennui et d'émergence d'une structure heureuse fonctionne probablement à tous les niveaux de modularité.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
12 votes
Je pense que c'est un raisonnable question compte tenu des exigences et des conventions des autres langues, et le réponse est "<définir les modules et paquets Python> et au-delà, c'est une question de préférence (/opinion)" -- cette réponse n'est pas en soi une opinion