python - ¿Cómo organizo módulos de manera coherente para una aplicación de escritorio PyGTK?

pyqt

Question

Estoy trabajando en una aplicación de escritorio en PyGTK y parece estar tropezando 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 poco compacta. Maneja callbacks de señal, etc.
• command.py - mantiene las 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

Hasta ahora, esto ha funcionado bastante bien, pero en este punto, application.py empieza a ser bastante largo. He examinado muchas otras aplicaciones PyGTK y parecen tener problemas estructurales similares. En 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.

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

¿Debería lidiar con tener un módulo central muy largo o hay una mejor manera de estructurar el proyecto para que no tenga que depender tanto del buscador de clases?

EDITAR I

Bien, punto tomado con respecto a todas las cosas de MVC. Tengo una aproximación aproximada de MVC en mi código, pero es cierto que probablemente podría ganar un poco de kilometraje segregando 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 hacer referencia a ella) y mi impresión es que no va a resolver mi problema sino solo formalizarlo. Mi aplicación es un archivo de glade único, generalmente una sola ventana. Así que no importa cuán estrictamente defina los roles MVC de los módulos, todavía tendré un módulo de controlador haciendo casi todo, que es más o menos lo que tengo ahora. Es cierto que estoy un poco confuso sobre la implementación apropiada de MVC y voy a seguir investigando, pero no me parece que esta arquitectura vaya a sacar más cosas de mi archivo principal, solo va a cambiar el nombre de esa arquitectura. archivo a controller.py

¿Debería pensar en pares separados de Controlador / Vista 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 el momento.

Answer 1

En el proyecto Wader usamos python gtkmvc , que hace mucho más fácil aplicar los patrones MVC al usar pygtk y glade, puede ver la organización de archivos de nuestro proyecto en el repositorio svn :

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

Answer 2

Esto probablemente no tiene nada que ver con PyGTK, sino más bien un problema general de organización del código. Probablemente se beneficiaría aplicando algunos patrones de diseño MVC (Modelo-Vista-Controlador). Ver patrones de diseño , por ejemplo.

Answer 3

Python 2.6 admite importaciones relativas explícitas , lo que hace que usar paquetes sea aún más fácil que las versiones anteriores. Le sugiero que busque romper su aplicación en módulos más pequeños dentro de un paquete. Puede organizar su aplicación de esta manera:

myapp/
application/
gui/
command/
state/

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

Answer 4

"tiene 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 One Class Does Everything no funcione. Puede que no sea lo que llamaría orientado a objetos. No parece que siga el patrón de diseño típico de MVC si su funcionalidad se acumula en una sola clase.

¿Qué hay en esta clase masiva? Sugiero que probablemente puedas refactorizar esto en pedazos. Usted tiene dos dimensiones candidatas para refactorizar su clase de aplicación, si, de hecho, he adivinado bien que ha puesto todo en una sola clase.

1. Antes de hacer nada más, refactorice en componentes que sean paralelos a las Entidades del mundo real. No está claro qué hay en tu "state.py": si este es un modelo adecuado de entidades del mundo real, o solo asignaciones entre el almacenamiento persistente y una estructura de datos turbia en la aplicación. Lo más probable es que transfiera 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 el control y ver elementos. El error de MVC más común 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 el refactor en componentes que son paralelos a la presentación de la GUI. Varios marcos de nivel superior, por ejemplo, probablemente deberían tener objetos cotrol separados. No está claro qué hay en "GUI.py": esta podría ser una vista correcta. Lo que parece faltar es un componente de control.

Answer 5

Entonces, al no haber escuchado sobre mi edición a la pregunta original, investigué un poco más y la conclusión a la que parece llegar es que sí , debería romper la interfaz en varias vistas, cada una con su propio controlador. Python-gtkmvc proporciona la capacidad de esto proporcionando un parámetro glade_top_widget_name para el constructor de View. Todo esto parece tener mucho sentido, aunque va a requerir una gran refacturación de mi código base existente que puedo o no estar dispuesto a asumir en el corto plazo (lo sé, lo sé, debería ). Por otra parte , Me pregunto si debería tener un solo objeto Model (mi aplicación es bastante simple, no más de veinticinco vars de estado) o si debería 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 alguna idea adicional, todavía no siento que haya obtenido una respuesta a la pregunta original, aunque ahora tengo una dirección a seguir.

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

Answer 6

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