¿Cómo organizo coherentemente los módulos para una aplicación de escritorio PyGTK?

Question

Estoy trabajando en una aplicación de escritorio en PyGTK y parece que estoy topando con algunas limitaciones de mi organización de archivos. Hasta ahora he estructurado mi proyecto de esta manera:

• application.py: contiene la clase de aplicación principal (la mayoría de las rutinas funcionales)
• gui.py: contiene una implementación de gui GTK acoplada libremente. Maneja señales de devolución de llamada, etc.
• command.py: contiene funciones de automatización de línea de comandos que no dependen de los datos en la clase de aplicación
• state.py: contiene la clase de persistencia de datos de estado

Esto ha funcionado bastante bien hasta ahora, pero en este punto application.py está empezando a ser bastante largo. He examinado muchas otras aplicaciones PyGTK y parecen tener problemas estructurales similares. En un cierto punto, el módulo primario comienza a ser muy largo y no hay una forma obvia de dividir el código en módulos más estrechos sin sacrificar la claridad y la orientación del objeto.

He considerado hacer de la GUI el módulo principal y tener módulos separados para las rutinas de la barra de herramientas, las rutinas de los menús, etc., pero en ese momento creo que perderé la mayoría de los beneficios de la POO y terminaré con un todo. -todo escenario.

¿Debo tratar de tener un módulo central muy largo o hay una mejor manera de estructurar el proyecto para no tener que depender tanto del navegador de clases?

EDIT I ??

Ok, así que punto tomado con respecto a todas las cosas MVC. Tengo una aproximación aproximada de MVC en mi código, pero debo admitir que probablemente podría ganar algo de kilometraje al segregar aún más el modelo y el controlador. Sin embargo, estoy leyendo la documentación de python-gtkmvc (que es un gran hallazgo por cierto, gracias por su referencia) y mi impresión es que no resolverá mi problema sino que simplemente lo formalizaré. Mi aplicación es un solo archivo glade, generalmente una sola ventana. Así que no importa qué tan bien defino los roles MVC de los módulos, todavía voy a tener un módulo de controlador haciendo casi todo, que es casi lo que tengo ahora. Admito que estoy un poco confuso en la implementación adecuada de MVC y voy a seguir investigando, pero no me parece que esta arquitectura vaya a sacar más cosas de mi archivo principal, simplemente va a cambiar el nombre de eso archivo a controller.py.

¿Debería estar pensando en pares de Controlador / Vista separados para secciones separadas de la ventana (la barra de herramientas, los menús, etc.)? Tal vez eso es lo que me estoy perdiendo aquí. Parece que esto es a lo que se refiere S. Lott en su segundo punto.

Gracias por las respuestas hasta ahora.

Answer 1

En el proyecto Wader usamos python gtkmvc , que facilita mucho la aplicación de los patrones MVC cuando se utilizan pygtk y glade, puede ver la organización de archivos de nuestro proyecto en svn repository :

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

Answer 2

Es probable que esto no tenga nada que ver con PyGTK, sino un problema general de organización de código. Probablemente se beneficiaría con la aplicación de algunos patrones de diseño MVC (Modelo-Vista-Controlador). Consulte Patrones de diseño , por ejemplo.

Answer 3

" contiene la clase de aplicación principal (la mayoría de las rutinas funcionales) "

Como en singular, ¿una clase?

No me sorprende que el diseño de Una clase hace todo no funciona. Puede que no sea lo que yo llamaría orientado a objetos. No parece que siga el patrón de diseño típico de MVC si tu funcionalidad se está acumulando en una sola clase.

¿Qué hay en esta clase masiva? Sugiero que probablemente puedas refactorizar esto en pedazos. Tienes dos dimensiones candidatas para refactorizar tu clase de aplicación, si, de hecho, he acertado que has puesto todo en una sola clase.

1. Antes de hacer cualquier otra cosa, refactorice en componentes que sean paralelos a las Entidades del Mundo Real. No está claro qué hay en tu " estado.py " - Si este es un modelo adecuado de entidades del mundo real, o solo asignaciones entre el almacenamiento persistente y alguna estructura de datos turbios en la aplicación. Lo más probable es que mueva el procesamiento de su aplicación a su modelo (posiblemente state.py, posiblemente un nuevo módulo que sea un modelo adecuado).

   Rompe tu modelo en pedazos. Ayudará a organizar los elementos de control y visualización. El error más común de MVC es poner demasiado control y nada en el modelo.

2. Más adelante, una vez que su modelo esté haciendo la mayor parte del trabajo, puede ver refactor en componentes que son paralelos a la presentación de GUI. Varios cuadros de nivel superior, por ejemplo, probablemente deberían tener objetos de cotrol separados. No está claro lo que hay en " GUI.py " - Esto podría ser una vista adecuada. Lo que parece faltar es un componente de Control.

Answer 4

Lamento responder tan tarde. Kiwi me parece una solución mucho mejor que gtkmvc. Es mi primera dependencia para cualquier proyecto pygtk.

Answer 5

Python 2.6 admite importaciones relativas explícitas , que hacen que el uso de paquetes sea aún más fácil que con versiones anteriores. Le sugiero que busque romper su aplicación en módulos más pequeños dentro de un paquete. Puedes organizar tu aplicación de esta manera:

myapp/
  application/
  gui/
  command/
  state/

Donde cada directorio tiene su propio __init__.py . Puede ver cualquier aplicación de Python o incluso módulos de biblioteca estándar para ver ejemplos.

Answer 6

Por lo tanto, no habiendo recibido respuesta sobre mi edición de la pregunta original, he investigado un poco más y la conclusión a la que parece que llego es que sí , debería dividir la interfaz en varios Vistas, cada una con su propio controlador. Python-gtkmvc proporciona la capacidad para esto al proporcionar un parámetro glade_top_widget_name al constructor View. Todo esto parece tener bastante sentido, aunque va a requerir una gran refactorización de mi base de código existente, que puedo o no estar dispuesto a realizar en el corto plazo (lo sé, lo sé, lo debería .) Además, me pregunto si debería tener un solo objeto Modelo (mi aplicación es bastante simple: no más de veinticinco vars estatales) o si debo dividirla en varios modelos y tener que lidiar con los controladores observando múltiples modelos y encadenando notificaciones a través de ellos. (Una vez más, sé que realmente debería hacer lo último.) Si alguien tiene una idea más, todavía siento que no he recibido una respuesta a la pregunta original, aunque tengo una Dirección para dirigirse ahora.

(Además, parece que deberían ser otras opciones arquitectónicas a la mano, dado que hasta ahora no había visto una sola aplicación Python codificada en el estilo MVC, pero nuevamente, muchas aplicaciones Python tienden a tener el problema exacto. he descrito anteriormente.)