Loading
Note di Apprendimento
Study Reminders
Support
Text Version

Interfacce Linea Di Comando a Graphical User Interfacce

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Ciao, benvenuto nello sviluppo di applicazioni moderne. In questa settimana studieremo la transizione dalle interfacce di riga di comando alle interfacce utente grafiche. E come parte di questa transizione, impareremolezioni su quali tipi di nuove idee devono essere coinvolte quando passiamo dalle nostre applicazioni di linea di comando di elaborazione batch di base ad applicazioni interattive con interfacce utente grafiche,e successive su quelle lezioni si tradurranno nel mondo dello sviluppo di applicazioni web.(Fare Slide Time: 00.48)
C'era una volta che tutti usavano interfacce di riga di comando perché quella era l'unica tecnologia che c'era in giro. Come il nostro progresso tecnologico abbiamo inventato l'idea migliore di un'interfaccia grafica utente. A questo punto, se tu avessi chiesto ai nostri utenti esattamente in che modo la nostra interfaccia grafica utente è migliore, allora potrebbero aver detto una cosa come se sembreranno migliori, e che sianopiù facili da usare.
Ma come programmatori dobbiamo disfare queste istruzioni per capire proprio cosa è cherende migliore le interfacce utente grafiche. E quello che è che rende le interfacce grafiche più facili da usare.La “ look migliore ” parte in una certa misura deriva dalla pura bellezza della grafica, soprattutto innostro giorno, dove le interfacce grafiche sono diventate straordinariamente eleganti ed esteticamentesoddisfacenti. Ma c'è un altro lato verso di esso.Oltre, gli sguardi che sono puri e semplici, le interfacce utente grafiche sono più cose come si sentonopiù vicini alla nostra esperienza di vita reale nell'usare le cose che ci sono intorno. Ad esempio, i pulsanti sono un esempio classicodi qualcosa che si traduce molto gentilmente dal mondo reale nell'interfaccia utente.Fin dai tempi delle lampadine elettriche, i pulsanti sono stati ubiquitari e quindi sono moltonaturali per noi da usare.
I pulsanti sono sembrati naturali prima di essere usati ai sistemi elettrici non mi sembranecessariamente vero per me. Questa idea è a volte chiamata skeuomorfismo, l'idea che tu siaimitando le cose nel mondo reale e usandole come interfacce a cose che non sono reali sul computer. Quindi questo è un senso in cui le interfacce utente grafiche sono più facili. Ma c'è di piùche anche solo l'aspetto o la somiglianza con le cose reali del mondo.Quello che troviamo è che la natura dell'interazione, l'esperienza stessa che l'utente ha di ciò che accadequando utilizzano interfacce grafiche è diverso da quello dell'utilizzo di un'interfaccia di riga di comando. Peruna cosa con GUI possiamo interagire più volte con un programma senza dover avviare estop a quel programma tutto il tempo. E questo significa che l'app può ora conservare il contesto perché imparadalla storia, ricorda quello che stava succedendo e puoi utilizzare queste informazioni per migliorare l'interazione dell'utente.
Vediamo un semplice esempio di come gestire il contesto storico rende le cose più facili, a partire dacon una semplice versione della nostra app. Ma la versione generale, più reale, della versione del semplice esempioche vedremo arriverà sotto un argomento chiamato interazione design. Questo non riguarda solo come un
l'applicazione sembra ma come è che un utente possa trovare l'applicazione naturale da utilizzare senza troppainterazione.
Un famoso libro chiamato About Face by Alan Cooper ha fatto per la prima volta l'idea di design di interazionepopolare, la prima edizione di questo libro a metà degli anni ' 90s e forse quel libro ha parlato di app desktope l'ultima edizione in circa 2014 ora copre, ad esempio, cose come le applicazioni mobili.Il nostro esempio sarà molto semplice. Ma quando si tratta di applicazioni complesse, vale la pena tenerea mente le distinzioni tra vari aspetti del design delle app.Un aspetto del design delle app è il design software interno del programma, che governa cose comequanto sia facile per un programmatore capire e cambiare applicazione. Un'altra dimensione diversaè il design visivo, che guarda se ci piace o meno l'aspetto dell'app. Questo è il lato più artisticodello sviluppo. E un terzo tipo di design è il design di interazione, che parla di come l'utentesperimenta le loro interazioni con la tua applicazione. Ora passiamo al nostro semplice esempio.(Fare Slide Time: 05.02)
Qui abbiamo uno screenshot di un modo semplice per mappare la nostra semplice applicazione di riga di comandoad un formato grafico. Consideriamo quali potrebbero essere le caratteristiche di tale app. Ad esempio, come
CLI, possiamo registrare un utente. E sembra chiaro che il modo in cui ci registriamo dovrebbe essere quello di digitare il nomedell'utente nel testo superiore colpirà il pulsante di registro, e l'utente dovrebbe essere registrato.Ovviamente, il nome utente va nel campo di testo.Allo stesso modo, sembra chiaro che dovremmo inserire le spese nel campo di testo e poi colpire il pulsante. L'area di testo inferiore è dove otterremo risposte come quello che è appena accaduto e quandosi preme il pulsante di report, ecco dove vedremo l'output. Quanti di voi accetterebberoche sembra naturale che i ruoli del campo di testo e l'area di testo più ampia siano evidenti. Non èinteressante che anche troppi di noi, anche gli utenti non tecnici saranno in grado di fare questo caso su quello chel'app sta facendo, e quindi, darci un modo abbastanza semplice per essere in grado di diventare utilizzabile,senza dover mai leggere un manuale, oppure istruire le persone su come fare queste cose.Questi idiomi di come la nostra interfaccia utente dovrebbe essere organizzata o per ora così naturale da noi, chesi sentono evidenti. E c'è ancora di più che saremmo considerati evidenti. Ad esempio, potremmoaspettarci l'app per ricordare chi è l'utente corrente e non richiederci di nuovo e specificare nuovamentel'utente che è qualcosa che dobbiamo fare in caso di applicazione della riga di comando, ad esempio.E anche i nostri amici non tecnici, se mostriamo loro questa app e devono inserire nuovamente il loro nomee di nuovo, faranno sicuramente un suggerimento che non sarebbe la tua app, basta ricordareil nostro nome. Un altro modo in cui avremmo potuto progettare l'app è semplicemente copiare semplicemente qualunque cosa sia la nostra app di riga di comandoe richiedere all'utente di digitare l'intero comando nel campo di testo. Mache non si sentirebbe diverso come un'app che ricorda il contesto.Così, in questo senso, questa comparsa di contesto, che persiste attraverso molteplici interazioni è ciò che èunivoco sulle interfacce utente grafiche, rispetto alle interfacce utente testuali offerte dal comandoline applicazioni.
(Riferimento Slide Time: 07.42)
Ora vediamo cosa succede quando iniziamo a usare il contesto in un modo ancora più, diciamo inventivao energico. Come esempio di ciò che può accadere, nella semplice app che consideriamo tutti i 3pulsanti dell'app è stato possibile premere non appena l'app si apre. Ma questo non è in realtà moltoutile perché fino a quando l'utente non è stato registrato, non è come se si possa fare qualsiasi cosa con gli altri 2pulsanti. Ma questa conoscenza ci dice che in realtà dovremmo avere una sorta di modo per dire all'utenteche certi pulsanti non sono d'uso proprio ora. E noi capiamo come fare una cosa del genere. Quindi, l'idea consuetaqui è quella di gridare certi pulsanti, se attualmente non hanno alcun utilizzo. Questo grattugiatofuori e funzioni come questo switch inizia a diventare sensibile al contesto, o una delle fonti chiave dicomplessità delle interfacce utente grafiche. Ad esempio, nell'app della riga di comando, tutte le stringhe di comandosono considerate valide quando entrano.E annunceremo che c'è un errore se così accade che l'utente entri in una sorta di stringaillegale. Ora, la domanda è cosa facciamo nel caso dell'interfaccia grafica utente. Una risposta è comeabbiamo visto: grattarsi fuori dai pulsanti. Ma decisioni come questa non sono davvero chiare. Alcunidesigner di interazione potrebbero sentire che lo stile del messaggio di errore è di fatto superiore. Perché se si premeun pulsante che non dovrebbe essere utilizzato, allora il programmatore potrebbe offrire un bel messaggio di errore chespiega chiaramente perché questo pulsante non è disponibile in questo momento, e cosa potrebbe fare l'utente invece.
In questo modo, il contesto cambia molte delle possibilità di interazione. Man mano che la storia diventa più profonda, ela quantità di caratteristiche che le offerte delle applicazioni diventano più complicate, l'interazione tracosa è successo finora e quindi cosa può accadere il futuro diventa più difficile da capire.Non fortunato o fortunatamente come utenti, piuttosto che come programmatori, si scopre che le piccole nuancescome questa sono davvero apprezzate dagli utenti.E quindi, si scopre che molti designer di interazione, e anche noi esperti come utenti dialtre applicazioni, diranno che è consigliabile avere caratteristiche così sensibili al contesto. Lecondizioni nell'app core però, come aggiungiamo queste cose iniziano a ballottare, e richiede un buondialogo tra progettisti di interazione e programmatori per capire cosa è fattibile e cosa èsostenibile sul lungo termine.(Fare Slide Time: 10.38)
Reliance sul contesto per parlare di ciò che un'app dovrebbe e non deve fare o può e non può fare,porta naturalmente all'idea di una sessione. Una sessione inizia quando viene lanciata un'app. Ci sono una seriedi interazioni e poi l'app è terminata. Una sessione mantiene il contesto nella memoriasoprattutto per gli strumenti desktop. Ed è abbastanza naturale poter conoscere facilmente cosa sta succedendo inun'app in cui tali informazioni possono essere conservate direttamente nella memoria.
Il tipo di contesto più comune, ad esempio è l'identità utente. Nella nostra app registrazione funziona ordinadi like login e possiamo dire all'utente corrente, dopo che si registrano, che il resto delle operazioni avverrànel contesto della loro identità. Come mostrato nello screenshot, la nostra applicazione può organizzarefacilmente per ricordare l'identità registrata. È importante mostrarlo agli utenti perché traaltre cose potrebbe essere possibile che più utenti potrebbero utilizzare questa app.E anche se questo non accade in un contesto molto comune, è importante anche segnalare agli utentiche qualche aspetto della precedente interazione, e esattamente quale aspetto, si rifletta nell'applicazione. Poiché siamo così familiari con le sessioni, l'idea di una sessione potrebbe sembraresemplice. E ovviamente, come utenti è un'idea semplice. Tuttavia, per un implementatore di applicazioni, le sessioninon sono così facili da implementare.Il motivo è che l'idea di una sessione, e la quantità crescente di contesti diversi che potrebberoesistere, iniziano ad aggiungere sempre più dimensioni ai dettagli interni di un programma. Ad esempio,supponiamo che oltre all'identità, acquisiamo una nozione del progetto corrente che un'applicazionedeve affrontare, una volta che c'è un progetto attuale ora per ogni singola struttura dati in programma,qui a cui pensare per quale identità e per quale progetto.Presto i casi iniziano a moltiplicarsi e poi alcune funzioni sono consentite per qualche identità, alcune sonoconsentite per alcuni progetti, alcune sono per alcune combinazioni e alcune sono dismesse. E quandoquesti tipi di opzioni si moltiplicano, la complessità continua ad aumentare. Ad esempio, pensa alla distinzionetra l'amministratore di un server contro l'utente di un servizio. Queste 2 identità,anche se sono la stessa persona in momenti diversi, possono avere conseguenze radicalmente diverse.E così, la logica interna dell'applicazione deve far fronte a questi tipi di variazioni. Ma particolare la proprietàche è comunemente associata alle sessioni aggiunge ulteriore complessità. E questo èpurtroppo la proprietà molto comune dell'identità.
(Riferimento Slide Time: 13.41)
Ecco un piccolo esempio di come potremmo usare l'identità. Supponiamo che ci siano 2 utenti Avinash eKalyan e poi Kalyan spende 40 rupie e poi chiede un rapporto. Report può utilizzare le informazionirelative all'utente corrente per artigianare la propria emissione in modo leggibile. È implicito che sta utilizzando l'applicazionee questo è utile. Ma come vedremo, nel caso del web, questo può rendere le coseabbastanza difficili.La maggior parte di noi è così abituata a registrarsi nelle nostre macchine, e diamo per scontato che la nostra identitàsarà implicita in tutte le nostre interazioni. Siamo abituati anche a pensare di registrarsi, registrandodi macchine condivise come la definizione stessa di sessioni. Ma l'identità è dura anche per le applicazioni desktop. Come esempio, una volta, i personal computer erano pensati per essere veramentepersonali, i telefoni sono e quindi sono stati progettati con una sola persona comunque.Ma è successo che la famiglia ha iniziato a condividerli e le istituzioni hanno iniziato ad offrire PC condivisi. Eora si è abbattuta l'idea di un personal computer. La transizione da un singolo utente a più utenteha richiesto profonde modifiche al sistema. Ad esempio, abbiamo dovuto aggiungere l'idea di proprietario ad ogni singolo file system. E così, qualcosa che è stato usato solo per lo stoccaggio senza pensare molto a chi èper tutto un improvviso ha dovuto affrontare la dimensione dell'identità.
Se l'identità è difficile per le app desktop, è ancora più difficile per le applicazioni web. Perché l'identità nel casodi web causa questioni come l'immedesimazione degli utenti e ora devi affrontare non solol'identità come usata internamente all'app per distinguere tra le cose, ma anche per affrontarevalidazione degli ID utente, determinando possibili falsi e cose del genere. Nel caso delle app locali CLI eGUI dato che il nostro accesso è protetto dalla registrazione su una macchina fisica.La distinzione che sto facendo potrebbe non sembrare importante, ma una volta diventata una designer di applicazioni, si scopre che molti siti web sono sotto costante attacco da parte di varie persone che avrebberocome entrare e usare le tue strutture per ogni sorta di cose strane, tra cui cose come quelle minerariebit sui tuoi server. Nel caso del web, l'imitazione diventa una questione molto seria. Undecennio o tanto tempo fa era possibile impersonare un altro utente semplicemente condividendolo correttamenteURL.
Oggigiorno, la maggior parte dei siti web hanno difese contro tali cose, ma anche se state attenti potresteaprire il vostro sito ad attacchi inavvertitamente, e passeremo un po' di tempo cercando di capire le ramificazioni di sicurezzaquando sorgeranno. Per ora, passiamo agli altri aspetti delle applicazioniinterattive che dobbiamo capire. La differenza chiave oltre la sessione e l'identità è la nozionedi un loop di eventi, che modifica la natura del flusso di controllo disponibile per un'applicazione.
(Riferimento Slide Time: 17.02)
Un'applicazione di riga di comando ha un flusso di controllo molto semplice, accetta l'input e produce il risultato.Questo è molto simile a come funzionano le funzioni in un linguaggio di programmazione. Al contrario, il flusso di controllo diun'applicazione GUI interattiva è più confusa. Non c'è niente di simile nella consueta programmazionelingue su cui possiamo contare per qualche esperienza. Il comportamento predefinito della GUI quando è iniziato èabbastanza diverso dal comportamento predefinito di un'app della riga di comando.considerando che un'app della riga di comando sta facendo immediatamente esattamente quello che hai detto a e niente di più,il comportamento predefinito della GUI quando è iniziato è mostrare l'interfaccia e poi non fare altro cheattendere il nostro input. Quando viene ricevuto un input, esegue il comando e torna a farenulla. In generale, sorprendentemente sulle nostre macchine, la CPU il disco etc. è inattivo per la maggior parte del tempo,a meno che non siamo programmi come i clienti che controllano se hai ricevuto un messaggio email oWhatsApp o qualcosa del genere, a parte che quella macchina non ha nulla da fare tranne che farequalunque cosa sia che l'utente desideri.
Così un tale attesa è sorprendentemente sufficiente un loop infinito, questo è uno dei rari casi in cui un loopinfinito è esattamente quello che si desidera, normalmente e un loop infinito nella normale programmazione, talecome un errore, ma in questo caso è esattamente ciò che si desidera, il programma dovrebbe loop per sempre,
basta attendere l'input dell'utente e ogni volta che riceve input, fare qualcosa di utile, tali input che sonoricevuti da questo infinito loop di attesa sono noti come eventi. E così, il loop si chiama evento. Ail più basso il loop di eventi o gli eventi che loop potrebbero interessare sono cose come i movimenti del mousee le tastiere e la GUI che si otterrà insieme ai sistemi operativi determina seil mouse che viene cliclato in una determinata parte dello schermo debba essere interpretato come aver innescatoun pulsante.
Così, ad esempio, converte in modo efficace l'evento premuto di mouse di livello inferiore in un pulsante di stampa di alto livelloe i programmi GUI e web sono scritti in termini di tali eventi di alto livello. Quindi, nonsolo il flusso di controllo insolita, abbiamo bisogno di un nuovo tipo di terminologia per affrontare questo, ovvero lenozioni di eventi e loop di eventi e rispondendo agli eventi. Un loop di eventi in un programma GUI èrelativamente semplice da capire e quindi passeremo un po' di tempo a parlarne. Ma i loop di eventinei programmi web possono esistere sul server, o il client il browser o entrambi. Inoltre, l'eventoloop nei sistemi web può servire contemporaneamente più utenti, a differenza del consueto evento GUIloop che servono solo un utente.Nelle seguenti slide vedremo come gli eventi delle sessioni e il codice della GUI sembrano nella nostra app. Noicostruiremo poi su questa conoscenza per studiare costruzioni simili nelle applicazioni web.
(Riferimento Slide Time: 20.24)
Cominciamo con la panoramica della struttura di base dell'applicazione dell'interfaccia utente, è possibilecreare una semplice app UI in cui la spinta di un pulsante viene mappata direttamente ad una chiamata di funzione. E questa chiamata di funzionecome qualsiasi altra chiamata di funzione in un programma normale andrebbe in giro ad aggiornare varie strutture dati. Vari semplici strumenti di building UI fanno questo approccio perché questo approccio èpiù facile da iniziare con.Tuttavia, l'esperienza ha dimostrato che mentre è facile iniziare con un programma, dove l'UIcontrolla come pulsanti e campi di testo direttamente trigger, tali app diventano ingestibili comenuovi requisiti nascono. Quello che succede è che il programma per ogni pulsante sta pensando in termini diquel pulsante, e non in termini di big picture. Se un programmatore diverso più tardi vuole capirecosa sta succedendo, alcune funzioni potrebbero sorgere accidentalmente, a seguito di strane interazioni tradiversi elementi di input e output di un programma.E hai davvero bisogno di più organizzazione per cercare di dare un senso a ciò che sta realmente accadendo nell'applicazione dell'interfaccia utente. Questo accade molto velocemente, anche per semplici app di seeming. Quindi, èinutile prendere un approccio più strutturato per la costruzione di un'applicazione di interfaccia utente. Questa soluzione, o una soluzione a questo problema di strutturazione, è qualcosa che la maggior parte dei programmi di interfaccia utente
dovrà trattare in un punto o in un altro. E la soluzione è abbastanza semplice che è meglioutilizzarla fin dall'inizio. Come vedremo, può essere usato in modo molto leggero e nondeve essere così complicato a tutti.Quello che abbiamo capito storicamente, era che questa sorta di separazione ha bisogno dei seguenti 2 elementi. Noiabbiamo strutturato l'applicazione in parti prevalentemente indipendenti, di solito, almeno 2 parti e spesso 3 oancora più parti.Un modo per separare le complessità di ciò che un'applicazione è stata fare contro come presentare chele informazioni sono da considerare che ci sono 3 aspetti. Ci sono strutture che sono necessarie per il calcolo. Questa parte che è responsabile del calcolo è chiamata modello. Un'altra parte chiamataa view, gestisce tutto il codice diretto per creare l'interfaccia utente e così diventa responsabile del display.E ci deve essere una terza parte che connette il modello e la vista, in modo da sapere quale elementodella vista influenza quali elementi del modello e possiamo collegarli insieme. Questo componenteè una sorta di metodo di cablaggio che connette un pulsante ad una lampada. Se ci sonopiù lampade e pulsanti multipli di quanto non sia il cablaggio che decide quale pulsante influenza quale lampadain questa metafora.A volte questo cablaggio è programmato esplicitamente e in altri stili chiamati programmazione reattivae molti altri tipi di cose. Il cablaggio è inferrato dalla struttura del programma. Per i nostri scopiresteremo con un semplice stile di cablaggio esplicito della programmazione. Quindi, una volta che queste 3parti sono al posto, cosa sta succedendo? L'idea è che l'utente di un'applicazione che sia perlopiùinteressata al lato del display, e non nella strutturazione interna, vede la vista e interagisce conit. Ma i dati che la vista mostra derivano dal modello sottostante. In modo efficace, la vista offreun modo per un utente di manipolare il modello sottostante. Quindi, ecco la struttura statica.E il caso dinamico, che ne è del comportamento? Per quel comportamento, organizziamo anche in una sequenzadi 3-phases:1. Nella prima fase un utente lavora con la vista e la vista accetta l'input dell'utente,2. poi determina quale parte del modello deve essere influenzata dall'input corrente,
3. e poi il cablaggio veicola il significato del gesto dell'utente, alla fine all'utente tramite la vista.
Una volta che il modello sa cosa vuole l'utente, il calcolo si verifica in diverse parti dei moderni datiaggiornati, poi le modifiche alla vista calcolate in base a quali modifiche si verificano nel modello. Questo modo di pensare3 - fase ci aiuta a organizzare chiaramente il programma. Per intenderci, inizieremooff con una versione ancora più semplice dell'applicazione che abbiamo già, e vediamo come funziona il modellodi ristrutturazione.(Fare Slide Time: 25:35)
Questa slide mostra una semplice applicazione utente e anche più semplice, che semplicemente registra gli utenti enon fa altro. Qui quando il pulsante di registrazione viene clicdito, l'utente corrente viene aggiornato e il risultatoviene mostrato. Il nostro modello qui è solo una semplice variabile che conosce l'utente corrente. Quindi:• Nella prima immagine che si vede, l'applicazione è come si vede quando si lancia.• E la seconda è dopo aver registrato un singolo utente, è possibile vedere l'utente corrente riflesso inl'etichetta che abbiamo mostrato.
Qui come ho detto, il modello è in realtà una cosa molto semplice. Si tratta semplicemente di quello che è che detiene il nomedell'utente corrente. La vista consiste nel pulsante, nel campo di testo e nell'etichetta. E ora esistono 2connessioni tra la vista: il campo di testo e il pulsante e un'altra parte della vista,che è l'etichetta.Che tipo di connessioni sono queste? il campo di testo e il pulsante agiscono come dispositivi di input che hanno modificatoil valore attualmente mantenuto del modello. E l'etichetta agisce come un dispositivo che ti mostra qual è il valore correntedel modello.
Quindi, una coppia di questi 2 elementi, il TextField e il pulsante si comportano come sistemi di input e l'etichettasi comporta come sistema di output. Il flusso di 3 fasi in questo caso è particolarmente semplice. Nella fase di input, l'utente riempie il campo di testo e preme il pulsante. Nella fase di calcolo, il modello memorizzail valore corrente del campo di testo, perché questo è tutto il calcolo che serve in questo caso.E poi non c'è niente di molto in più, l'output deve essere mostrato ogni qualvolta il modellocambia. Quindi, questo è l'esempio principale. Anche in qualcosa di semplice come questo, questa discussionedella distinzione tra la vista e il modello e il sistema di output in ingresso a 3 fasi, lo fahelp un po' per capire come si potrebbe andare in giro a strutturare anche il semplice programma UIcosì. Ok, ora a qualcosa di più complicato, dove diamo un'occhiata a come funzionano queste ideequando guardiamo i dettagli maggiori.
(Riferimento Slide Time: 28:11)
Quindi, diamo un'occhiata alla struttura concettuale di ciò che avviene nel caso di un'applicazione di modello view. In questa slide studieremo come è effettivamente organizzato il codice. Quindi, se date un'occhiata,vedrete che in alto c'è il triangolo che rappresenta nell'utente. C'è un rettangolo arrotondatoche rappresenta la vista e intorno a questa vista c'è un costrutto looping chiamato loop eventocome abbiamo parlato, la vista a sua volta interagisce con il modello tramite elementi chiamati handlers e il modellointeragisce con l'archivio dati via memoria IO.L'utente interagisce con il loop dell'evento tramite eventi e il loop dell'evento organizza l'interazione dell'utentee ne fornisce uno dopo l'altro alla vista. Così, quando abbiamo costruito la nostra interfaccia utente effettiva, noiabbiamo elementi nel programma che corrispondono direttamente a questi blocchi concettuali. Quegli elementidel programma sono stati elencati di seguito. E dal momento che stiamo costruendo questo in Java, la maggior parte degli elementisi riferisce alle classi Java che vengono utilizzate per costruire questi sistemi.Così, corrispondente alla vista, abbiamo delle classi UI Java, di tipo JButtton, JTextArea e JTextFieldcorrispondenti ai gestori, le classi gestore Java come ActionListener sono utilizzate per connetterela vista al modello. Il modello per i tipi di sistemi che stiamo osservando sono semplicemente strutture daticome HashSet e HashMap, e ovviamente qualsiasi altra classe che si potrebbe desiderare diprogettare e utilizzare per il calcolo.
La parte IO di memoria viene gestita da file IO, JDBC e varie altre classi IO, alcune delle qualisi sono già incontrate per la scrittura dell'applicazione della riga di comando. E l'archivio dati per il nostro caso di utilizzocomunque è solo un semplice database in file. In qualche modo, allora tutto il vero codice che scriviamo deve inserirciin questo tipo di modello per avere la struttura che vorremmo, in modo da capire cosa sonole dipendenze e cosa – come cresce l'applicazione, come gestire la distinzione traciò che serve per la visualizzazione e ciò che serve per la modellazione.Vediamo come la 3 ° fase del loop di output di calcolo di input si adatta a questo modello. Quindi, in questo caso, quello che abbiamo è che c'è l'utente che si digita in qualcosa, e quando l'utente faqualcosa, fa scattare il loop dell'evento, che poi guida l'ActionListener. Poi questa è la partedove abbiamo accettato l'input.A questo punto i gestori vengono attivati e il modello viene catturato. Questa è la parte compatte. Euna volta che il calcolo del nuovo stato del modello è completo, a turno, il modello racconta la vistache ci sono alcuni aspetti della vista che gli oggetti della vista dovrebbero essere aggiornati. E questa è la partela dove il flusso di controllo si pone in cima alle strutture dati che abbiamo visto. Nel resto diquesto, non parleremmo molto dello store dei dati, ci sarà solo sullo sfondo.Perché qui non c'è nulla di nuovo che sta andando avanti rispetto all'applicazione della riga di comando.Avanti, diamo un'occhiata al codice che corrisponde alle strutture concettuali che abbiamovisto.
(Riferimento Slide Time: 31:56)
Così, vediamo. Ok, qui andiamo ok. Quindi, slide numero 12. In questa slide guardiamo alle parti diil codice scritto per creare l'applicazione che abbiamo già visto. In questa cosa, come tuguarda a destra, io sto usando Eclipse, ma non c'è un motivo particolare per cui intendo dire che non sto rendendoqualsiasi raccomandazione su quale IDE dovresti usare, usare qualunque cosa ti trovi a tuo agio.Qui vediamo quelle parti dell'applicazione che corrispondono alle cose concettuali che abbiamovisto.
E come si possono vedere gli elementi che vengono utilizzati per creare il modello e la vista sono molto, moltosemplici. Non abbiamo nemmeno molto per mezzo di oggetti, ovviamente, cose come Set, e così via, eci sono oggetti Java nelle librerie. Ma questo design non è particolarmente orientato. Il motivoera che non volevo alcuna struttura in più. Volevo solo dimostrare che anche le strutture semplici possonomappa molto chiaramente nella struttura della vista modello che abbiamo già visto.Per facilità di riferimento ho replicato il diagramma di visualizzazione del modello sul basso a sinistra di questa slide.Quindi, facciamo un veloce walkthrough del codice che vediamo qui. Così, la classe si chiamaModelViewExampleParts, e inizia mostrando il modello. Il modello in questo casoè costituito da veramente 2 variabili, una delle quali è un set, e l'altra, ovvero una stringa. myUserssono tutti gli utenti che hanno registrato, e una stringa currentUser è l'utente che in realtà noimostreremo in etichetta.
Sotto che è la vista complessiva contiene, si tratta di un frame, che è uno dello stile standard Java diche organizza GUI in codice Java. E l'elemento della vista che ci interessa è ovviamente,solo un JLabel. Tutto questo è guidato dalla consueta sorta di programma principale. E poi si hanno i seguenti metodi3, che costituiscono gli elementi che portano al flusso di controllo a 3 fasi che abbiamodiscusso.