INF1010 MVC i tekstbaserte programmer

Like dokumenter
INF1000 Metoder. Marit Nybakken 16. februar 2004

Dagens forelesning. Java 13. Rollefordeling (variant 1) Rollefordeling (variant 2) Design av større programmer : fordeling av roller.

Grafisk Brukergrensesnitt

INF1000. Marit Nybakken 10. februar 2004

Løsningsforslag til eksamen i INF1000 våren 2006

Løsningsforslag ukeoppg. 4: sep (INF Høst 2011)

(MVC - Model, View, Control)

INF1010 Sortering. Marit Nybakken 1. mars 2004

Gjennomgang av eksamen H99

INF1000 Behandling av tekster

Innhold uke 4. INF 1000 høsten 2011 Uke 4: 13. september. Deklarasjon av peker og opprettelse av arrayobjektet. Representasjon av array i Java

UNIVERSITETET I OSLO

OPPGAVE 5b og 8b Java Kode

INF1010 Tråder J. Marit Nybakken Motivasjon. Å lage en tråd

Eksamensoppgaver 2014

Enkle generiske klasser i Java

INF1000 Eksamen 2014 (modifisert)

Løsningsforslag ukeoppg. 9: okt (INF Høst 2011)

INF1000 EKSTRATILBUD. Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen

Oblig 4Hybelhus litt mer tips enn i oppgaven

Kom forberedt til tirsdag. INF1000 Tips til obligatorisk oppgave 4. Noen generelle tips. Oblig4: Komme igang

Objektorientert design av kode. Refaktorering.

UNIVERSITETET I OSLO

INF1000 (Uke 5) Mer om løkker, arrayer og metoder

UNIVERSITETET I OSLO

Repetisjon. INF gruppe 13

Uke 8 Eksamenseksempler + Ilan Villanger om studiestrategier. 11. okt Siri Moe Jensen Inst. for informatikk, UiO

1. Finn klassene (hvilke objekter er det i problemet) 1. Dataene som beskriver problemet (hvilke objekter har vi og hvor mange klasser er det?

Oblig4 - forklaringer. Arne og Ole Christian

Endret litt som ukeoppgave i INF1010 våren 2004

JavaScriptbibliotek. Introduksjon MVVC. Informasjonsteknologi 2. Gløer Olav Langslet Sandvika VGS

Oblig 3 tips litt mer tips enn i oppgaven

Forelesning inf Java 5

GUI («Graphical User Interface») del 2

OBJEKTER SOM EN PROGRAMMERINGS-TEKNIKK

Forelesning inf Java 5

INF1000 (Uke 14) Resten av eksamen H03 + del av V05

Verden - Del 2. Steg 0: Oppsummering fra introduksjonsoppgaven. Intro

INF1010 våren Grensesnitt

INF Seminaroppgaver til uke 3

Gjennomgang prøveeksamen oppgave 1, 2, 4, 5, 7

Oppgave 1 (Programtolkning) INF1000 Eksamen V06. Oppgave 1 (Programtolkning) Oppgave 1 (Programtolkning)

INF Løsning på seminaropppgaver til uke 8

UNIVERSITETET I OSLO

INF1010 våren januar. Objektorientering i Java

INF1000: noen avsluttende ord

INF100 Institutt for informatikk Universitetet i Bergen Øving 5

INF1000: Forelesning 6. Klasser og objekter del 1

Argumenter fra kommandolinjen

Hva er verdien til variabelen j etter at følgende kode er utført? int i, j; i = 5; j = 10; while ( i < j ) { i = i + 2; j = j - 1; }

Innhold. INF1000 Høst Unified Modeling Language (UML) Unified Modeling Language (UML)

Verden - Del 2. Intro. Skrevet av: Kine Gjerstad Eide

INF1010 Rekursjon. Marit Nybakken 1. mars 2004

Hvis en person har inntekt < , så betaler han 10% skatt på alt, og ellers betaler han 10% skatt på de første og 30% på resten.

Hvis en person har inntekt < , så betaler han 10% skatt på alt, og ellers betaler han 10% skatt på de første og 30% på resten.

Lenkelister. Lister og køer. Kopi av utvalgte sider fra forelesningen.

INF1000 Prøveeksamen Oppgave 7 og 9

Ordliste. Obligatorisk oppgave 1 - Inf 1020

Øvingsforelesning 5 Python (TDT4110)

Kapittel 13: Grafiske brukergrensesnitt INF 100. Java som første programmeringsspråk

Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF Høst 2011)

UNIVERSITETET I OSLO

INF1000 (Uke 15) Eksamen V 04

INF1000 (Uke 15) Eksamen V 04

Sudokubrettet Et sudokubrett består av n n ruter. Vi bruker følgende begreper i oppgaven:

UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet

INF 1010, vår 2005 Løsningsforslag uke 11

Rekursjon. Binærsøk. Hanois tårn.

IN1010 våren januar. Objektorientering i Java

INF1000 Klasser og objekter

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS

UNIVERSITETET I OSLO

. Ved sensur vl1 ahe bokstaverte deloppgaver (a, b, c,...) telle like mye.

Praktisk informasjon. I dag. Repetisjon: While-løkker. INF1000 (Uke 5) Mer om løkker, arrayer og metoder

INF Uke 10. Ukesoppgaver oktober 2012

INF1010, 15. januar time. Parametriserte klasser (generiske klasser) Stein Gjessing Inst. for Informatikk Universitetet i Oslo

Antall sider (inkl. forsiden): 7. Alle trykte og håndskrevne

Øvingsforelesning 5 Python (TDT4110)

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

Øvingsforelesning 1 Python (TDT4110)

Prøveeksamen inf november Arne Maus og Ole Christian Lingjærde

INF1010 Arv. Marit Nybakken 2. februar 2004

i=0 Repetisjon: arrayer Forelesning inf Java 4 Repetisjon: nesting av løkker Repetisjon: nesting av løkker 0*0 0*2 0*3 0*1 0*4

Forelesning inf Java 4

Fra krav til objektdesign

INF1000 Eksamen 2014 (modifisert)

HØGSKOLEN I SØR-TRØNDELAG

Forflytning. oblig 2 : INF h oktober 2012

Tre måter å lese fra terminal. Java 4. Eksempel. Formatert utskrift til skjerm

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

UNIVERSITETET I OSLO

Oppgave 1. Oppgave 2. Oppgave 3. Prøveeksamen i INF1000. Ole Christian og Arne. 23. november 2004

UNIVERSITETET I OSLO

Prøveeksamen i INF1000. Ole Christian og Arne. 23. november 2004

Oppsummering. Kort gjennomgang av klasser etc ved å løse halvparten av eksamen Klasser. Datastrukturer. Interface Subklasser Klasseparametre

Velkommen til. INF våren 2012

INF1010 siste begreper før oblig 2

INF1000 Mer om objekter

Transkript:

INF1010 MVC i tekstbaserte programmer Marit Nybakken marnybak@ifi.uio.no 9. februar 2004 Marit har ingen utdanning innen systemutvikling og vet antageligvis ikke hva hun prater om. Hun har dog skumlest noen artikler under sterk påvirkning av koffein. MVC-designet var opprinnelig laget for programmer med grafisk brukergrensesnitt, og det er nok ikke rett frem hvordan man overfører dette til tekstbaserte programmer. Derfor vil dere høre litt forskjellige løsninger avhengig av hvilken gruppelærer dere spør. Model - View - Control Vi skal altså forsøke å dele opp programmene våre i tre deler: View : styrer grafisk eller tekstlig utskrift til skjerm om statusen til modellen. Viser altså rett og slett frem hvordan modellen ser ut akkurat nå. Control : tar i mot input fra mus og keyboard fra brukeren om ønskede endringer av systemet. Ber modellen endre på seg ut i fra dette. Model : holder datamodellen, styrer oppførselen til dataene. Tar i mot forespørsler om informasjon om status (fra view) og forespørsler om å endre status (fra kontroll). Skal også gi view beskjed når den har endret seg slik at view kan oppdatere. 1

Et GUI-eksempel Vi skal først se hvordan dette vil fungere i et program med grafisk brukergrensesnitt. Vi tenker oss et eksempel der vi har en grafisk modell av en liten harepus. Vi har et vindu som viser frem harepusen på skjerm. Det skal være mulig å legge til punkter på harepusen ved hjelp av musen. View er nå vinduet som viser frem harepusen på skjerm. Model er den grafiske modellen, representasjonen av harepusen, kanskje en rekke punkter som det skal trekkes linjer mellom. Control er den delen som lytter på musen og ber modellen legge til punkter ut i fra hvor brukeren klikker. Se figur 1. Hvordan foregår kommunikasjonen her? Kontroll har en peker til modellen. Hver gang den får inn et museklikk, oversetter den dette til koordinater og kaller en metode modell.leggtilpunkt(x,y); i modellen, den oppdaterer modellen. View må kunne vite når harepusen har fått flere punkter for å kunne oppdatere skjermbildet med den nye harepusen. Modellen har derfor en peker til View og sier i fra via et metodekall (eventuelt et slags signal) view.endringskjedd() når leggtilpunkt-metoden blir kalt. View kan deretter få de oppdaterte dataene gjennom en parameter til endringskjedd() (et slags oppdateringsobjekt med nødvendig informasjon) eller den kan ved behov kalle en metode i modellen, Data d = modell.fådata() for å hente ut de dataene den selv mener den har behov for. I det siste tilfellet må View ha en peker til modellen. Hva er egentlig problemet? Når vi har et grafisk brukergrensesnitt er det enklere å forestille seg hvordan ting bør fungere. For view har vi et eller flere vinduer som på en eller annen 2

Figur 1: Kommunikasjon mellom view, control og model 3

Figur 2: Kommunikasjon mellom view, control og model, tekstbasert? 4

fin måte til enhver tid viser frem hvordan modellen ser ut. Modellen sender ut signaler når den endrer seg. I mange språk trenger ikke modellen engang vite hvem som skal fange opp disse signalene. View registrerer seg for å motta signaler fra modellen, og oppdaterer seg når den mottar et signal. I et tekstbasert program med en meny blir modellen kun vist frem når vi ber om det gjennom et menyvalg. Dette gjør at koden blir helt annerledes. Tekstbasert løsning Vi har i oblig 1 en situasjon der noen av menyvalgene dreier seg om å vise frem deler av modellen (vis person, vis søsken, fetter/kusine, flest barn), og noen dreier seg om å endre modellen (ny person, ny far/mor, ekteskap, skilsmisse). De som dreier seg om å endre modellen er ren kommunikasjon mellom kontroll og modell (kontroll: endre på deg! modell: jepp, ferdig, gikk bra!). Dette fungerer omtrent som det ville gjort for et grafisk grensesnitt. Kontrolldelen i et grafisk grensesnitt kan heldigvis også bestå av et eget kontrollvindu med knapper, tekstfelt, slidere og statusmeldinger. Dette gir grunnlag for å la kontroll skrive ut ting på skjermen, den også. De som dreier seg om å vise frem modellen er noe man kanskje kunne tenkt seg ville være på skjermen hele tiden når man har grafisk brukergrensesnitt. Input kreves for noen av fremvisningene, f.eks. navn til person som skal vises frem, og dette kan gis via tekstfelt og knapper. Disse tekstfeltene vil i såfall være en del av views kontroll, ikke modellens kontroll, som bare dreier seg om å endre på modellen (jepp, vi kan ha flere kontroller). Vi skulle gjerne ha beholdt vårt gode gamle system med en ordreløkke som tar seg av alle menyvalg, selv om de nå i og for seg tilhører to forskjellige kontrollsystemer. Men vi kan slå sammen viewkontroll og modellkontroll til en kontroll, og da kan hele menyen befinne seg på samme sted. Menyvalg som har med endring av modell å gjøre resulterer i kall på metoder i modellen. Menyvalg som har med fremvisning å gjøre resulterer i kall på metoder i view. View må deretter kalle passende metoder i modellen for å hente ut informasjonen den skal vise frem. Eventuelle input til hva som skal vises frem, f.eks. navnet til personen, skal leses inn i Kontroll (dette tilsvarer tekstfeltet og knappene som kontrollerer view). 5

I det hele tatt... Se på figur 2 du. Eksempel på kode class Kontroll { View view; Register reg; void ordrelokke() { // Skriv ut meny // Les inn valg switch(valg) { 10 case 1: leggtilperson(); break; case 2: visperson(); break; // osv... void leggtilperson() { // Les inn navn, mor, far, kjønn System.out.print("Navn: "); String navn = tast.intext(); // Osv... // Be register om å oppdatere modellen boolean ok = reg.leggtilperson(navn, mor, far, kjønn); 20 if(ok) { 30 System.out.println("Gikk fint ja"); else { System.out.println("Dette gikk åt skogen"); void visperson() { System.out.print("Navn: "); String navn = tast.intext(); 40 // Be view om å vise frem modellen 6

view.visperson(navn); class Register { // Modell HashMap personer = new HashMap(); 50 boolean leggtilperson(string navn, String mor, String far, char kjønn) { //... if(!personer.containskey(navn)) { // Legge til fyren/dama //.... return true; else{ return false; 60 String visperson(string navn) { // Finne person og lage infotekst om ham // Et alternativ her kunne vært å bare returnere peker til personen return info; 70 class View { Register reg; void visperson(string navn) { String res = reg.visperson(navn); System.out.println(res); void vissøsken(string navn) { String res = reg.vissøsken(navn); System.out.println(res); 80 // osv... 7

Kontroll får altså lov til å skrive på skjerm når den ber om input fra tastaturet og skrive ut resultatet av oppdateringer av modellen (som stort sett blir feilmeldinger eller det-gikk-fint-meldinger). Når modellen skal vises frem, er det View som tar seg av utskriften på skjerm. 8