PDA

Visualizza la versione completa : Far dialogare Core e GUI


davidinho
16-03-2013, 00:39
Faccio una domanda forse stupida ma alla quale avendo un'esperienza pressoché nulla non saprei dare una risposta, non si tratta di un linguaggio in particolare...

Mettiamo che io crei un programma composto da soltanto 5 classi più le varie classi per l'interfaccia grafica, di solito come si fa per far dialogare grafica e core?
Non so ad esempio si crea una classe principale per il core la quale viene passata come argomento al costruttore di una classe principale creata per la grafica?

Forse ho detto una grande stupidata, ma come già detto ho pochissima esperienza...

MItaly
16-03-2013, 02:49
Di solito per le cose che faccio la parte di elaborazione è ben separata dalla parte grafica, per cui scrivo la parte di "business logic" del programma come se fosse una libreria, magari collaudandola man mano con un'applicazione console. Quindi procedo a creare la parte GUI, che non fa altro che istanziare/usare le classi della parte scritta precedentemente.

rsdpzed
16-03-2013, 08:32
Io del core scrivo solo le interfacce senza implementazione. creo una classe che racchiude tutti i riferimenti di quelli che saranno gli oggetti che implementeranno quelle interfacce in modo da non dovermi preoccupare, dalla GUI, della struttura logica delle classi di business: ho solo una classe (vedi design pattern Facede). Questa operazione va fatta in modo da non sottovalutare la gestione della memoria che è qualcosa che cambia da ambiente ad ambiente.
Poi passo allo sviluppo della GUI, nelle cui classi passo o creo un riferimento alla classe del core. Anche qui occhio alla gestione della memoria. A questo punto nelle classi GUI sviluppi solo soluzioni inerenti alla parte visuale del programma e ti affidi a chiamate al core, attraverso la classe "facede", quando ti servono operazioni di logica.
Quando hai bisogno di testare l'applicazione (testare è una parola generica che va dal vero test al semplice "farla partire") implemento una versione "fake" dei metodi richiamati dalle parti di GUI che andrò a provare. Questo garantisce che qualsiasi problema venga fuori in questa fase non sia un problema di core ma un problema di GUI.

Durante lo sviluppo della GUI Puo succedere (e succede) di accorgermi che quello che avevo pensato essere la corretta organizzazione delle classi del core non è esattamente quello che in realtà serve al sistema. Per esempio, devo cancellare un metodo, spostarlo in un altra classe, cambiare i parametri ecc. Questo è normale perche attraverso lo sviluppo della GUI si è piu vicini alle specifiche che il sistema deve avere e alle richieste dell'utente (l'utente preme pulsanti, guarda delle schermate non richiama API e non legge risultati xml). In questa fase però non ci sono grosse perdite di tempo perche alla fine tutto cio che vado a cambiare sono solo le interfacce del core.

Se sono soddisfatto implemento la vera versione dei metodi fake e sostituisco la classe fake con quella reale. La classe che decide se istanziare un oggetto fake o un oggetto "reale" è la classe facede, per la gui è tutto trasparente. Questa è una fase "cerniera" che chiude il cerchio tra GUI e core.

Questo in modo molto generico è quello che faccio io in ambienti managed e prevalentemente in applicazioni lato server (asp.net). Quello che posso dirti e confermarti dall'esperienza (esperienze negative e positive) è che quanto piu sei severo nell'importi questo tipo di sviluppo, tanto piu l'applicazione sarà "resistente" ai cambiamenti che DI SICURO ti verranno chiesti nel tempo.

davidinho
16-03-2013, 11:56
Io del core scrivo solo le interfacce senza implementazione. creo una classe che racchiude tutti i riferimenti di quelli che saranno gli oggetti che implementeranno quelle interfacce in modo da non dovermi preoccupare, dalla GUI, della struttura logica delle classi di business: ho solo una classe (vedi design pattern Facede).
Quindi in pratica ti crei una classe che contiene tutti i metodi che possono essere richiamati dall'utente, metodi che in questa classe si limitano a richiamare poi i metodi delle classi corrette, cioè questa classe principale raccoglie le richieste dell'utente per poi passarle alla classe corretta, giusto? anche se non ho capito bene cosa intendi con la frase "del core scrivo solo le interfacce senza implementazione"...


Quando hai bisogno di testare l'applicazione (testare è una parola generica che va dal vero test al semplice "farla partire") implemento una versione "fake" dei metodi richiamati dalle parti di GUI che andrò a provare. Questo garantisce che qualsiasi problema venga fuori in questa fase non sia un problema di core ma un problema di GUI. cioè crei dei metodi fake che non fanno nulla? mi sa che non ho capito molto bene questa parte

Loading