Comment organiser des modules de manière cohérente pour une application de bureau PyGTK?

Question

Je travaille sur une application bureautique sous PyGTK et je parais me heurter à certaines limites de mon organisation de fichiers. Jusqu'ici, j'ai structuré mon projet de la manière suivante:

• application.py - contient la classe d'application principale (les routines les plus fonctionnelles)
• gui.py - contient une implémentation de l’interface graphique GTK faiblement couplée. Gère les rappels de signal, etc.
• command.py - contient les fonctions d'automatisation de la ligne de commande indépendantes des données de la classe d'application
• state.py - contient la classe de persistance des données d'état

Cela a assez bien fonctionné jusqu'à présent, mais application.py commence à être assez long. J'ai examiné de nombreuses autres applications PyGTK et elles semblent avoir des problèmes structurels similaires. À un moment donné, le module principal commence à devenir très long et il n’existe aucun moyen évident de diviser le code en modules plus étroits sans sacrifier la clarté et l’orientation des objets.

J'ai envisagé de transformer l'interface graphique en module principal et de créer des modules distincts pour les routines de la barre d'outils, des menus, etc., mais à ce stade, je vais perdre la plupart des avantages de la programmation orientée objet et me retrouver avec une référence à tout. -Tout scénario.

Devrais-je simplement gérer un très long module central ou existe-t-il un meilleur moyen de structurer le projet de manière à ne pas trop me fier au navigateur de classes?

MODIFIER I

D'accord, c'est donc un élément important à prendre en compte dans le MVC. J'ai une approximation approximative de MVC dans mon code, mais certes, je pourrais probablement gagner du temps en séparant davantage le modèle et le contrôleur. Cependant, je suis en train de lire la documentation de python-gtkmvc (ce qui est d'ailleurs une excellente découverte, merci de l'avoir référencée) et j'ai l'impression que cela ne résoudra pas mon problème au lieu de le formaliser. Mon application est un fichier Glade unique, généralement une fenêtre unique. Donc, peu importe la précision avec laquelle je définis les rôles MVC des modules, je vais toujours avoir un module de contrôleur qui fait presque tout, ce qui est à peu près ce que j'ai maintenant. Certes, je suis un peu flou sur la bonne implémentation de MVC et je vais continuer à faire des recherches, mais il ne me semble pas que cette architecture obtienne plus de données de mon fichier principal, elle va juste changer de nom. fichier sur controller.py.

Devrais-je penser à des paires contrôleur / vue séparées pour des sections distinctes de la fenêtre (la barre d’outils, les menus, etc.)? C'est peut-être ce qui me manque ici. Il semble que ce soit ce à quoi S. Lott se réfère dans son deuxième point.

Merci pour les réponses reçues jusqu'à présent.

Answer 1

Dans le projet Wader , nous utilisons python gtkmvc , qui facilite beaucoup l’application des modèles MVC lorsqu’on utilise pygtk et glade, vous pouvez voir l’organisation des fichiers de notre projet dans référentiel svn :

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/

Answer 2

Cela n’a probablement rien à voir avec PyGTK, mais plutôt à un problème d’organisation générale du code. Vous auriez probablement intérêt à appliquer certains modèles de conception MVC (Model-View-Controller). Voir Modèles de conception , par exemple.

Answer 3

"contient la classe d'applications principale (la plupart des routines fonctionnelles)"

Comme au singulier - une classe?

Je ne suis pas surpris que le design One Class Does Everything ne fonctionne pas. Ce n'est peut-être pas ce que j'appellerais orienté objet. Il ne semble pas que cela corresponde au modèle de conception MVC typique si votre fonctionnalité s’empile dans une seule classe.

Qu'y a-t-il dans cette classe massive? Je suggère que vous puissiez probablement reformuler ceci en morceaux. Vous avez deux dimensions candidates pour restructurer votre classe d’applications - si, en effet, j’ai bien deviné que vous avez tout mis dans une seule classe.

1. Avant toute chose, reformulez les composants en parallèle avec les entités du monde réel. Le contenu de votre " state.py " - qu'il s'agisse d'un modèle approprié d'entités du monde réel ou simplement de mappages entre le stockage persistant et une structure de données trouble dans l'application. Très probablement, vous déplaceriez le traitement de votre application dans votre modèle (éventuellement, state.py, éventuellement un nouveau module correspondant à un modèle approprié.)

   Brisez votre modèle en morceaux. Cela vous aidera à organiser les éléments de contrôle et de vue. L’erreur la plus courante chez MVC est de mettre trop de contrôle et rien dans le modèle.

2. Plus tard, une fois que votre modèle aura effectué la plus grande partie du travail, vous pourrez examiner le refactorisation dans des composants en parallèle avec la présentation de l'interface graphique. Par exemple, divers cadres de niveau supérieur devraient probablement avoir des objets cotrol distincts. Le contenu de & GUI.py " n'est pas clair. - cela pourrait être une vue appropriée. Ce qui semble manquer est un composant de contrôle.

Answer 4

Désolé de répondre si tard. Le Kiwi me semble une bien meilleure solution que gtkmvc. C’est ma première dépendance pour tout projet pygtk.

Answer 5

Python 2.6 prend en charge Importations relatives explicites , qui rendent l’utilisation des packages encore plus simple que les versions précédentes Je vous suggère de diviser votre application en modules plus petits dans un package. Vous pouvez organiser votre application comme suit:

myapp/
  application/
  gui/
  command/
  state/

Où chaque répertoire a son propre __ init __. py . Vous pouvez consulter n'importe quelle application python ou même des modules de bibliothèque standard pour obtenir des exemples.

Answer 6

Alors, n'ayant pas eu de nouvelles de ma question initiale, j'ai effectué d'autres recherches et la conclusion à laquelle je semble en venir est que oui , je devrais diviser l'interface en plusieurs vues, chacune avec son propre contrôleur. Python-gtkmvc offre cette possibilité en fournissant un paramètre glade_top_widget_name au constructeur View. Tout cela semble logique, même si cela va nécessiter une refactorisation importante de ma base de code existante, que je ne suis peut-être pas prêt à entreprendre à court terme (je sais, je sais, je devrais .) De plus, je me demande si je ne devrais avoir qu'un seul objet Model (mon application est assez simple - pas plus de vingt-cinq vars), ou si je devais le diviser en plusieurs modèles et traiter avec les contrôleurs observant plusieurs modèles et enchaînant les notifications entre eux. (Encore une fois, je sais que je devrais vraiment faire la dernière chose). Si quelqu'un a des idées plus approfondies, je n'ai toujours pas vraiment l'impression d'avoir obtenu une réponse à la question initiale, bien que j'ai direction à se diriger maintenant.

(En outre, il semble qu’il faille faire d’autres choix architecturaux, étant donné que jusqu’à présent, je n’avais jamais vu une seule application Python codée dans le style MVC, mais bon nombre d’applications Python ont tendance à poser le même problème. 'ai décrit ci-dessus.)