Newsgroup: it.istruzione.universita.ingegneria
Titolo: Progettare delle UI correttamente

Salve a tutti ,
ho qualche difficoltà a progettare UI e non riesco a capire devvero il motivo ...
bell'inizio :-)
dunque ,
sono in ambiente Object Oriented , client Side .
- Modello resiede sul Client , 1 Classe Principale, una trentina di sottoOggetti interno bla bla ;
- dataBase resiede sul Client (documento XML, diciamo "database" vabbe' ) ;
non ha importanza , ma forse vi interessa ....
Problema :
il mio ciclo di svilupo è :
. Analisi
. Progettazione
. Implementazione
quando scrivo i miei progetti ,
creo dei programmi di TEST di sistema , e mi traccio i risultati su una piccola consolle di visualizzazione ..
in questo modo scrivo il Modello ma senza UI ...
ora il modello funziona ,
devo creare la UI ... esatto ?
faccio un'analisi dei requisiti ,
e mi blocco .
Non riesco a implementare correttamente MVC , e neppure Document/View quindi ....
Non riesco a capire come faccio a LEGARE la UI al MODELLO ...
Cioe' ,
il mio modello NON è stato progettato per mostrare dati ma per scambiare messaggi e lavorare con oggetti ,
devo ritornare alla fase di progettazione e convertire ogni VISTA in una Classe ?
e quindi il vocabolario di sistema aumentera' di altre "n" classi ?
Sono un pò confuso ,
non riesco a pensare ...
letture ?
Consigli ?
Libri ?
So analizzare,progettare,implementare un Modello ,
So analizzare,progettare,implementare una UI con MVC ,
ma non riesco a capire come diavolo faccio prendere il mio modello ed associargli una UI...
Non riesco a capire con quale logica si integrano i 2 mondi ....
Fiz

[cut]
La classe principale del modello dovrebbe esportare una serie di metodi che
rappresentano le operazioni eseguibili sul modello stesso.
La UI non deve far altro che:
1 - Prendere gli input dell'utente
2 - Convertirli nella forma adatta per esere passati ai metodi del modello
3 - Chiamare il/i metodo/i del modello
4 - Convertire l'output nella forma adatta per essere visualizzata sul video
Il progetto della UI si riconduce alla definizione di una gerarchia di
classi che soddisfano i 4 punti sopra.
Se trovi difficolta' nel fare questo forse non hai scelto correttamente i
metodi pubblici della classe principale del modello.
Chiaramente questa e' una ipotesi, fammi sapere cosa ne pensi.
Ciao, Davide :)

Quindi tu dici :
ho un Modello principale , che è visto come una Scatola Nera .
La scatola è il mio intero Programma ;
Prendiamo un Lettore MP3 come esempio ,
tu dici che l'oggetto LettoreMP3 dovrebbe contenere metodi pubblici che permettono l'intero funzionamento ?
è quello che ho pensato anche io ,
in questo modo ho un Oggetto interamente configurabile tramite Codice ;
ma non sono sicuro che sia corretto :)
un lettore MP3 dovrebbe avere i seguenti metodi pubblici :
- caricaMusica();
- onConnectToFile(); // invocato quando riesco a collegarmi al file
- onChangeSecond(); // invocato quando i secondi di ripdoruzione cambiano
- onChangeBuffering(); // invocato quando il Buffer di streaming cambia
- getSpeedDownload(); // ritorna la velocità di downstream utente
di conseguenza ,
potrei anche avere un Oggetto LettoreMP3 che contiene diciamo ... una trentina di metodi pubblici ?
Fiz

 potrei anche avere un Oggetto LettoreMP3 che contiene diciamo ... una
trentina di metodi pubblici ?
Certo. La scelta dei metodi e' un punto molto delicato. Devi rendere
pubblici tutti i metodi che servono sia alla view che al controller ma
niente piu'.
Ciao, Davide :)

: Certo. La scelta dei metodi e' un punto molto delicato. Devi rendere
: pubblici tutti i metodi che servono sia alla view che al controller ma
: niente piu'.
Perfetto ,
ti ringrazio delle risposte !
Anche se a questo punto ho qualche dubbio sull'applicabilità di MVC su Programmi molto interattivi e Vasti ;
Ad esempio ,
su un PlayerMP3 mi conviene NON avere 1 Oggetto grande ,ma diciamo 3 Piccoli a questo punto
- PlayerMP3 (play,stop,rewind,loadSong...)
- DataBase (Locale x le canzoni)
in programma a questo punto non sarebbe più :
P  = new PlayerMP3();
V = new View(P);
ma sarebbe :
P  = new PlayerMP3();
V = new View(P);
P2 = new DatabaseLocale(P); // aggregazione dell'oggetto P
V2 = new ViewDatabase(P2); //  la view per il database
Cosi' riesco a gestire meglio le VISTE , esatto ?
Xo' ,
quando devo creare una nuova versione del programma devo "ripetere" l'istanziazione di 2 oggetti ,
e se fossero 3,4,5,6,7 ?
bhe ,
dovrei portarmi dietro una diecina di linee di codice di istanziazione ..
è ancora lecito ?
Ed in più ,
credo ancora di commettere errori :
- il mio libro di OOP dice che in fase di OOD bisogna considerare tutte le schermate di visualizzazioni ,
ed ogni schermata deve essere convertita inuna Classe !
Quindi la UI inizia a farsi sentire già in fase di OOD a questo punto , e c'è qualcosa che non mi torna ...
uhmm...
io sviluppo dei sistemi molto molto interattivi ,
che dentro di loro creano istanze di decine di oggetti ...
esempio :
ho un Oggetto Libro che dentro di se crea un elenco di Capitoli da un oggetto XML ;
ogni capitolo crea dentro di se 20 sezioni ...
sono Oggetti che sono DENTRO al modello principale ,
c'è qualcosa che mi dice Che non è lecito mettere 20 mila Listener sul Modello per avvisare di ogni COSA la View...
Hai (avete) libri da consigliare ?
analisi,progettazione,implemetazione del modello li ho assimilati perfettamente.
la UI anche , ma per piccoli programmini insignificanti ...
per i grossi sistemi , ho difficoltà ...
2 sono le risposte :
1) MVC non si adatta a sistemi complessi ed esiste un Pattern diverso e più indicato
2) sbaglio la OOD perchè gia' da li dovrei includere la UI (mi sembra assurdo...)
3) [lo so , erano 2...] - sono cretino io :-))
Fiz