Comment organiser correctement un arbre de dépendance de module/module?

Question

Bonjour,

J'écris actuellement une librairie python. À l'heure actuelle, les modules et les classes sont déployés de manière non organisée, sans conception raisonnée. À l'approche d'une version plus officielle, je voudrais réorganiser les classes et les modules afin qu'ils aient un meilleur design global. J'ai dessiné un diagramme des dépendances d'importation, et je prévoyais d'agréger les classes par niveau de couche. En outre, je considérais une modification des classes afin de réduire ces dépendances.

Quelle est votre stratégie pour une bonne conception globale d'une bibliothèque python potentiellement complexe et en cours de création? Avez-vous des suggestions intéressantes?

Merci

Mise à jour:

Je cherchais en effet une règle générale. Par exemple, supposons que ce cas se produit (initialisation py pour plus de clarté)

foo/bar/a.py 
foo/bar/b.py 
foo/hello/c.py 
foo/hello/d.py 

maintenant, si vous arrive d'avoir d.py importer bar.b et a.py hello.c importation, je considère c'est un mauvais réglage. Un autre cas serait

foo/bar/a.py 
foo/bar/baz/b.py 
foo/bar/baz/c.py 

supposons que a.py et b.py importent c. vous avez trois solutions: 1) b importe c, une importation baz.c 2) vous déplacez c dans foo/bar. a.py importe c, b.py importe .c 3) vous déplacez c ailleurs (disons foo/cpackage/c.py) et ensuite a et b import cpackage.c

J'ai tendance à préférer 3) , mais si c.py n'a pas de signification en tant que module autonome, par exemple parce que vous voulez le garder "privé" dans le paquet de barre, je préférerais 1).

Il existe de nombreux autres cas similaires. Ma règle de base est de réduire au minimum le nombre de dépendances et de passages, afin d'éviter une configuration fortement ramifiée et fortement imbriquée, mais je peux me tromper.

Answer 1

"J'ai dessiné un diagramme des dépendances d'importation, et je prévoyais d'agréger les classes par niveau de couche."

Python doit se lire comme l'anglais (ou toute autre langue naturelle.)

Une importation est une déclaration de première classe qui devrait avoir un sens réel.Organiser les choses par «niveau de couche» (quel qu'il soit) devrait être clair, significatif et évident.

Ne faites pas de regroupements techniques arbitraires de classes en modules et modules en packages. Rendez les modules et le package évidents et logiques afin que la liste des importations soit évidente, simple et logique. "En outre, je considérais une modification des classes pour réduire ces dépendances." Réduire les dépendances sonne technique et arbitraire

Ce n'est peut-être pas le cas, mais ça sonne comme ça. Sans exemples concrets, c'est impossible à dire.

Votre objectif est la clarté.

En outre, le module et le package sont des unités autonomes de réutilisation. (Non classes, une classe, mais elle-même n'est généralement pas réutilisable.) Votre arbre de dépendance devrait refléter cela. Vous visez des modules qui peuvent être importés proprement et proprement dans votre application.

Si vous avez beaucoup de modules liés de près (ou d'implémentations alternatives) alors les paquets peuvent être utilisés, mais utilisés avec parcimonie. Les bibliothèques Python sont relativement plates. et il y a de la sagesse dans ça.

---

Modifier

dépendance à sens unique entre les couches est une caractéristique essentielle. C'est plus sur la conception de logiciels appropriés que sur Python. Vous devriez (1) concevoir en couches, (2) concevoir de sorte que les dépendances soient très strictes entre les couches, et ensuite (3) implémenter cela en Python.

Les emballages ne s'adaptent pas nécessairement parfaitement à vos couches. Les paquets peuvent être physiquement une liste plate de répertoires avec les dépendances exprimées seulement par les instructions import.

Answer 2

La question est très vague.

Vous pouvez réaliser ceci en ayant des choses de base/de base qui n'importent rien du reste de la bibliothèque, et des implémentations concrètes qui importent d'ici. Mis à part "ne pas avoir deux modules importés les uns des autres à l'importation", vous devriez aller bien.

module1.py:

import module2 

module2.py:

import module1 

Cela ne fonctionnera pas!

Answer 3

Cela dépend du projet, n'est-ce pas? Par exemple, si vous utilisez une conception de modèle-vue-contrôleur, votre package sera structuré de manière à rendre les 3 groupes de code indépendants.

Si vous avez besoin d'idées, ouvrez votre répertoire de packages de sites et examinez le code de ces modules pour voir comment ils sont configurés.

Il n'y a pas de manière correcte sans en savoir plus sur le module; Comme Ali a dit, c'est une question vague. Vous avez juste besoin d'analyser ce que vous avez devant vous et de trouver ce qui pourrait mieux fonctionner.