Come organizzare coerentemente i moduli per un'applicazione desktop PyGTK?

Question

Sto lavorando su un'applicazione desktop in PyGTK e sembra che stia affrontando alcune limitazioni della mia organizzazione di file. Finora ho strutturato il mio progetto in questo modo:

• application.py: contiene la classe di applicazione primaria (la maggior parte delle routine funzionali)
• gui.py - contiene un'implementazione della gui GTK liberamente accoppiata. Gestisce le richiamate del segnale, ecc.
• command.py: mantiene le funzioni di automazione della riga di comando non dipendenti dai dati nella classe di applicazione
• state.py - contiene la classe di persistenza dei dati di stato

Finora è andato abbastanza bene, ma a questo punto application.py inizia a diventare piuttosto lungo. Ho esaminato numerose altre applicazioni PyGTK e sembrano avere problemi strutturali simili. A un certo punto il modulo primario inizia a diventare molto lungo e non c'è modo ovvio di suddividere il codice in moduli più stretti senza sacrificare la chiarezza e l'orientamento degli oggetti.

Ho considerato di rendere la GUI il modulo principale e di avere moduli separati per le routine della barra degli strumenti, le routine dei menu, ecc., ma a quel punto credo che perderò la maggior parte dei vantaggi di OOP e finirò con un riferimento a tutto -tutto scenario.

Dovrei semplicemente avere un modulo centrale molto lungo o esiste un modo migliore di strutturare il progetto in modo da non dover fare così tanto affidamento sul browser di classe?

MODIFICA I

Ok, quindi punto preso per quanto riguarda tutte le cose MVC. Ho una approssimazione approssimativa di MVC nel mio codice, ma devo ammettere che probabilmente avrei potuto guadagnare un po 'di chilometraggio segregando ulteriormente il modello e il controller. Tuttavia, sto leggendo la documentazione di python-gtkmvc (che è un'ottima scoperta, grazie per averlo fatto riferimento) e la mia impressione è che non risolverà il mio problema, ma solo formalizzarlo. La mia applicazione è un singolo file glade, generalmente una singola finestra. Quindi, non importa quanto strettamente definisca i ruoli MVC dei moduli, avrò ancora un modulo controller che fa quasi tutto, il che è praticamente quello che ho ora. Devo ammettere che sono un po 'confuso sulla corretta implementazione di MVC e continuerò a fare ricerche, ma non mi sembra che questa architettura tirerà fuori altre cose dal mio file principale, sta solo per rinominare che file in controller.py.

Dovrei pensare a coppie Controller / View separate per sezioni separate della finestra (la barra degli strumenti, i menu, ecc.)? Forse è quello che mi manca qui. Sembra che questo sia ciò a cui si riferisce S. Lott nel suo secondo punto elenco.

Grazie per le risposte finora.

Answer 1

Nel progetto Wader utilizziamo python gtkmvc , che semplifica notevolmente l'applicazione dei modelli MVC quando si usano pygtk e glade, è possibile vedere l'organizzazione dei file del nostro progetto in repository svn :

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

Answer 2

Questo probabilmente non ha nulla a che fare con PyGTK, ma piuttosto un problema generale di organizzazione del codice. Probabilmente trarrai vantaggio dall'applicazione di alcuni modelli di progettazione MVC (Model-View-Controller). Vedi Pattern di design , per esempio.

Answer 3

" contiene la classe di applicazione primaria (la maggior parte delle routine funzionali) "

Come al singolare - una lezione?

Non mi sorprende che il design One Class Fa Tutto non funzioni. Potrebbe non essere quello che definirei orientato agli oggetti. Non sembra che segua il tipico modello di progettazione MVC se la tua funzionalità si accumula in una singola classe.

Cosa c'è in questa classe di massa? Suggerisco che probabilmente lo puoi trasformare in pezzi. Hai due dimensioni candidate per il refactoring della tua classe di candidatura - se, davvero, ho indovinato che hai messo tutto in una singola classe.

1. Prima di fare qualsiasi altra cosa, rifletti in componenti paralleli alle Entità del Mondo Reale. Non è chiaro cosa c'è nel tuo " state.py " - se questo è un modello proprio di entità del mondo reale, o solo mappature tra memoria persistente e una struttura di dati oscura nell'applicazione. Molto probabilmente ti sposteresti l'elaborazione fuori dalla tua applicazione e nel tuo modello (possibilmente state.py, forse un nuovo modulo che è un modello corretto.)

   Rompi il tuo modello in pezzi. Aiuterà a organizzare il controllo e visualizzare gli elementi. L'errore MVC più comune è quello di mettere troppo sotto controllo e niente nel modello.

2. Successivamente, una volta che il modello sta eseguendo la maggior parte del lavoro, è possibile esaminare il refactor in componenti paralleli alla presentazione della GUI. Vari frame di livello superiore, ad esempio, dovrebbero probabilmente avere oggetti cotrol separati. Non è chiaro cosa c'è in " GUI.py " - questa potrebbe essere una visione corretta. Ciò che sembra mancare è un componente di controllo.

Answer 4

Mi dispiace rispondere così tardi. Kiwi mi sembra una soluzione molto migliore di gtkmvc. È la mia prima dipendenza per qualsiasi progetto pygtk.

Answer 5

Python 2.6 supporta esplicite importazioni relative , che rendono l'utilizzo dei pacchetti ancora più semplice rispetto alle versioni precedenti. Ti suggerisco di scomporre l'app in moduli più piccoli all'interno di un pacchetto. Puoi organizzare la tua applicazione in questo modo:

myapp/
  application/
  gui/
  command/
  state/

Dove ogni directory ha il proprio __init__.py . Puoi dare un'occhiata a qualsiasi app python o persino ai moduli di libreria standard per esempi.

Answer 6

Quindi, non avendo sentito parlare della mia modifica alla domanda originale, ho fatto qualche ricerca in più e la conclusione a cui mi sembra di arrivare è che sì , dovrei dividere l'interfaccia in più viste, ognuna con il proprio controller. Python-gtkmvc fornisce la possibilità fornendo un parametro glade_top_widget_name al costruttore View. Tutto ciò sembra avere un buon senso, anche se richiederà un ampio refactoring della mia base di codice esistente che potrei o non sarò disposto a intraprendere a breve termine (so, lo so, dovrei .) Inoltre, mi chiedo se dovrebbe avere un solo oggetto Model (la mia applicazione è abbastanza semplice - non più di venticinque varianti di stato) o se dovrei suddividerlo in più modelli e avere a che fare con controller che osservano più modelli e concatenano notifiche tra loro. (Ancora una volta, so che dovrei fare quest'ultimo.) Se qualcuno ha ulteriori approfondimenti, non mi sento ancora davvero come se avessi una risposta alla domanda originale, anche se ho un direzione in cui andare adesso.

(Inoltre sembra che dovrebbero esserci altre scelte architettoniche a portata di mano, dato che fino ad ora non avevo visto una singola applicazione Python codificata nello stile MVC, ma poi molte applicazioni Python tendono ad avere il problema esatto I sopra descritto.)