Observer Pa*ern och MVC. Objekt-orienterad programmering och design Alex Gerdes, 2018

Relevanta dokument
Observer Pattern och MVC. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Observer Pattern och MVC. Objekt-orienterad programmering och design Alex Gerdes, 2016

Observer Pattern och MVC. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2017

Model View Controller. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Generics och polymorfism. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Generics och polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Två designmönster, MVC och Observer/Observable. Objektorienterad programvaruutveckling GU (DIT011)

Properties. Användbara metoder som kan anropas i propertychanged:

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Principles of subclasses. Objekt-orienterad programmering och design Alex Gerdes, 2018

ITK:P1 Föreläsning 4. Grafiska gränssnitt i Java. AWT-komponenter

Separation of Concern. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Lösningar till tentamen i EDAF25

Objektorienterad Programkonstruktion. Föreläsning 6 23 nov 2015

Model View. View Controller. Model View Controller. Observer. GrIP-vt2010-GUI-programmering Cristian Bogdan

Principles of subclasses Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

DAT043 - Föreläsning 7

Föreläsnings 11 - GUI, Händelsestyrda program, MVC

Mutability och State. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

UML. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU

The Last Adventure. Innehåll. Objektorientering. Språket Java. Java - Paket. Java - synlighet. Den sista lektionen. Repetition.

Design och konstruktion av grafiska gränssnitt

Design Patterns. Objekt-orienterad programmering och design Alex Gerdes, 2016

Design Patterns. Objekt-orienterad programmering och design Alex Gerdes, 2018

Objektorienterad Programkonstruktion. Föreläsning jan 2016

Lösningar till tentamen i EDAF25

Separation of Concern. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 3

Objekt-orienterad programmering och design. DIT953 Niklas Broberg, 2018

Tentamen i EDAF25. 1 juni Skrivtid: Skriv inte med färgpenna enda tillåtna färg är svart/blyerts.

Objektorienterad programmering med Java Swing: Händelser, lyssnare och applets

Principer, Pa+erns och Tekniker. Objekt-orienterad programmering och design Alex Gerdes, 2018

Fönstersystem. Objektorientering och händelsebaserad programmering. Applikation. Interaktionstoolkit. Händelsehanterare och grafiktoolkit

Dependencies High cohesion, low coupling. Objekt-orienterad programmering och design Alex Gerdes, 2018

Designmönster/Design patterns

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document

Modulär design. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Denna vecka. Idag. Grafiskt användarsnitt. Vi kommer att se

Objekt-orienterat vs funktionellt Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Objekt-orienterad Programmering och Design. TDA551 Alex Gerdes, HT-2016

TDDE10 m.fl. Objektorienterad programmering i Java Föreläsning 7 Erik Nilsson, Institutionen för Datavetenskap, LiU

Javas Exceptions. DD2385 Programutvecklingsteknik Fler bilder till föreläsning 7 23/ Kort om Javas Exceptions Trådar i Java

Swing. MER Java Foundation Classes (JFC) Hur lära sig? Vad är farorna. LayoutManagers. Exempel på några av komponenterna

Föreläsning 8 - del 2: Objektorienterad programmering - avancerat

Lösningsförslag till tentamen i EDAF25 Objektorienterad modellering och design Helsingborg

Objektorienterad Programkonstruktion, DD1346. Tentamen , kl

Design och konstruktion av grafiska gränssnitt

Swing. MER Java Foundation Classes (JFC) Vad är farorna. Hur lära sig? LayoutManagers. Exempel på några av komponenterna

Vad utmärker ett bra gränssnitt?

Spelet i sig är inte avancerat men projektet ställer en del krav på implementationen bland annat:

Föreläsning 17 UTBLICK: FORTSÄTTNINGSKURSER I DATAVETENSKAP + ANDROID

Objekt-orienterad Programmering och Design. TDA552 Alex Gerdes, HT-2018

Lab5 för prgmedcl04 Grafik

Projekt 2 XL. Observer-mönstret

Sammanfattning och Tentamensinfo Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Objekt-orienterat vs funktionellt Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2017

Tentamen i Objektorienterad programmering

Subtyping, co- och contra-variance. Objekt-orienterad programmering och design Alex Gerdes, 2016

Tentamen i Objektorienterad modellering och design

Tentamen. 2D4135 vt 2005 Objektorienterad programmering, design och analys med Java Lördagen den 28 maj 2005 kl

Subklasser och arv Inledning till grafik (JFrame och JPanel). Något om interface. Objektorienterad programvaruutveckling GU (DIT011) Subklasser

DVGB05 Grafiska användargränssnitt. Mjukvarudesign med Model-View-Controller

DUGGA: Objektorienterade applikationer. Läs detta! Uppgifterna är inte avsiktligt ordnade efter svårighetsgrad.

Tentamen. DD2385 Programutvecklingsteknik vt Fredagen den 5 juni 2009 kl Inga hjälpmedel utom penna, sudd och linjal

Principer, Patterns och Tekniker. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Computer projekttid. Objektorienterad modellering och diskreta strukturer / design. Rapporter från verkligheten. EDAF10 i HT2

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 5. Laboration 4 Lådplanering Exempel på grafik, ett avancerat program Frågor

MVC-mönstret. model-view-control i Swing

Grundläggande teori för användargränssni3, del 1

Tung bakgrundsaktivitet t.ex. Aktiva objekt t.ex. Animering, simulering. DD2385 Programutvecklingsteknik Några bilder till föreläsning 9 6/5 2013

PROGRAMMERINGSTEKNIK TIN212

LULEÅ TEKNISKA UNIVERSITET

2I1049 Föreläsning 5. Objektorientering. Objektorientering. Klasserna ordnas i en hierarki som motsvarar deras inbördes ordning

2I1049 Föreläsning 8. Grafiska gränssnitt i Java. AWT-komponenter. Grafiska gränssnitt, Java interface och händelsehantering

Vad utmärker ett bra användargränssnitt?

DI-institutionen Sid 1 av 6 Hans-Edy Mårtensson Sten Sundin

Laboration 3 GUI-programmering

Tentamen i Objektorienterad programmering

GUI-programmering. Gustav Taxén Martin Berglund DH2640 Grafik och Interaktionsprogrammering VT 2008

Föreläsning 15 (16) Historik (java.awt) Historik (javax.swing) Introduktion till Swing

Högskolan Dalarna sid 1 av 7 DI-institutionen Hans-Edy Mårtensson Sten Sundin

Objekt-orienterat vs funktionellt Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Designmönster, introduktion. Vad är det? Varför skall man använda mönster?

Grundläggande programmering, STS 1, VT Sven Sandberg. Föreläsning 18

DUGGA: Objektorienterade applikationer. Läs detta! Uppgifterna är inte avsiktligt ordnade efter svårighetsgrad.

Modulär design Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Kort om klasser och objekt En introduktion till GUI-programmering i Java

Dependencies High cohesion, low coupling. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Mer om grafiska komponenter. Händelsestyrda program

Principer, Patterns och Tekniker. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 3

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer.

Objektorienterad Programkonstruktion. Föreläsning 3 7 nov 2016

Dagens program. Programmeringsteknik och Matlab. Vad är arv? Vi ärver från GregorianCalendar. Kan vi bygga vidare på existerande klasser?

Föreläsning 10. ADT:er och datastrukturer

Objektorienterad Programkonstruktion. Föreläsning 3 9 nov 2015

Klasser som datastrukturer

TENTAMEN I DATAVETENSKAP

Transkript:

Observer Pa*ern och MVC Objekt-orienterad programmering och design Alex Gerdes, 2018

Model View Controller Model View Controller (MVC) är e2 design pa2ern (architectural pa2ern) som är väldigt vanligt förekommande för alla typer av program som innehåller någon form av grafisk representabon. Grunden i MVC är a2 vi separerar: Koden för data-modellen (M) från användargränssni2 (V och C). De2a är den vikbgaste uppdelningen. Inom användargränssni2 skiljer vi koden som visar upp (delar av) modellen för användaren (V) från koden som hanterar input från användaren (C).

Model Modellen (Model) är en representa0on av den domän som programmet arbetar över helt oberoende av användargränssni9. Data, 0llstånd, domänlogik. Modellen i singular vi har inte flera modeller för samma domän. Modellen kan dock internt bestå av flera olika delar som representerar olika aspekter av domänen (dvs ingen duplicering). Tumregel för avgränsning från V och C: Tänk The whole model and nothing but the model. Ska kunna presenteras för och kontrolleras av användaren på olika se9 e.g. med 2D-grafik eller text utan a9 valet i sig påverkar e.g. modellens 0llstånd. Nothing but the model Ska innehålla allt det som vore detsamma oavse9 hur modellen presenteras eller kontrolleras. Ingen0ng ska behöva dupliceras mellan olika vy- eller kontroll-komponenter. The whole model

View En vy (View) beskriver (delar av) modellen för användaren. Olika tänkbara format: Text, grafik (2D, 3D, ), ljud, hapik, Vi pratar om vy, oavsek vilket format presentaionen görs på. Vi kan ha många olika vyer (oma samidigt) för en och samma modell. Olika vyer kan visa upp olika aspekter av modellen. E.g. karta, inventory, synfält för ek dataspel. Olika vyer kan visa upp samma aspekt på olika format E.g. musik spelas upp, och visas samidigt grafiskt som frekvens-amplitud-diagram. Vi vill (omast) ak vyn uppdateras när modellen den presenterar uppdateras.

Controller En Controller styr modell och vy(er) u4från input från användaren. Vi kan ha många controllers som styr olika aspekter av både modell och vy. Olika varianter av MVC använder controllers lite olika: all4från en enskild controller som styr alla aspekter av modell och vyer, 4ll många separata controllers för varje del-vy. De flesta moderna grafik-gränssnij (som Java Swing) innehåller stöd för aj förenkla för controllers aj hantera användar-inputs genom events och event listeners.

Smart, Dumb, Thin Tumregel: SMART models, DUMB views, THIN controllers All domänlogik ska ligga i modellen därav SMART. En view ska inte göra egna beräkningar, bara visa ugfrån direkgv därav DUMB. En controller ska enbart hantera ylre input, dvs (ooast) input från användare. Den ska bara vara el tunt lager mellan användare och program därav THIN. YLre input måste inte vara från användare direkt; det kan komma e.g. via nätverkskommunikagon, från avläsning av sensorer, etc. DeLa är vad vi strävar eoer. Det är dock inte allgd helt självklart vad som bör ligga var (mer senare).

View: Visar upp en del av världen View: Listar info om karaktärer i modellen Fler views View: Visar en logg över händelser

Controller: Interaktion med saker i världen Controller: Interagerar med karaktärer Fler Fler controllers views Controller: Får saker att hända

Var går gränsen? Ponera en grafisk widget som...... visar informa5on från modellen.... går a8 klicka på så a8 saker händer. Controller eller vy? Svar: Som regel lite av båda (men går a8 göra undantag): Själva widgeten (e.g. JPanel) är rimligen (en del av koden för) en vy. Widgeten/vyn kan hantera a8 och hur användaren interagerar med den men inte vad som ska hända som effekt av de8a. Koden som avgör vad som ska hända hör 5ll en controller.

Var går gränsen? Ponera en grafisk widget som...... inte visar informa5on från modellen.... går a8 klicka på så a8 saker händer. Controller eller vy? Pilarna är ren input påverkar vad som visas i vyn bredvid. Svar: Man kan resonera olika men är e5ke8erna verkligen vik5ga? Det finns inget som säger a8 en Controller inte får ha en grafisk representa5on. Är de8a då en vy som visar up controllern (iställetför modellen som brukligt)? Eller är det en del av controllern? Who cares! Det vik5ga är a8 förstå principerna för a8 separera koden för de olika delarna.

Applika'on Alla applika(oner har en main -metod som går a6 exekvera. Denna hör inte (ll någon av MVC, utan ligger separat ( A ). Applika(onen skapar, sammanför, och startar de olika komponenter som (llsammans ska ueöra jobbet. Flera olika applika(oner kan använda sig av samma sorts komponenter, e.g. polygoner. Kan vara mer eller mindre avancerad, beroende på hur mycket som behöver konfigureras. Fönsterhanteringen på toppnivå kan ligga här. All data som är applika(onsspecifik kan ligga här. (Ibland (som undantag) är det relevant a6 lägga viss applika(onslogik här, istället för i M. E.g. I en simulering, hör (den hemma i modellen, eller kan olika applika(oner välja a6 hantera (den olika?)

Hur bör M, V och C (och A) hänga ihop? Vilka beroenden bör vi ha? M får inte bero av V eller C. Punkt. Världen är vad den är, oavse= hur den presenteras eller styrs. Får V bero av M? Får V bero av C? Får C bero av M och/eller V? Svar: Det beror på... Olika varianter kan vara relevanta i olika sammanhang. Lyssna inte på de som säger sig ha hi=at den enda sanningen. Tumregel: Gör det som leder Lll högst cohesion och lägst coupling! A väljer vilka delar av M, V och C som ska utgöra programmet. Slutsats: A beror nästan allld på samtliga delar. Om inte har du verkligen rä= uppdelning av M, V och C? A representerar e= topp-nivå-program inget ska någonsin bero på A!

Live code Signal

JPanel + paint(graphics) : void JFrame + paint(graphics) : void Speed <<enum>> SUPERFAST FAST NORMAL SLOW SUPERSLOW + up(): Speed + down() : Speed Signal - status : SignalStatus - speed : Speed - view : SignalView + run() : void + speedup() : void + slowdown() : void SignalApp + main(string[]) : void SignalView + update(signalstatus) : void SignalStatus <<enum>> RED TOGREEN GREEN TORED + next(): SignalStatus

Signal - status : SignalStatus - speed : Speed - view : SignalView + run() : void + speedup() : void + slowdown() : void SignalView + update(signalstatus) : void SignalApp + main(string[]) : void

Hur vänder vi på beroenden? Vi har e( dilemma. Om M inte får bero av V hur ska då V få veta när den ska uppdateras? Alterna>v 1: V frågar M regelbundet ( polling ), och ritar ut status. Fungerar bra om M uppdateras oha och mycket. Ex real>dsspel. Fungerar dåligt om M uppdateras sällan eller lite. Ex ritprogram. Alterna>v 2: C uppdaterar både M och V sam>digt. Fungerar bra om M enbart uppdateras på grund av användar input. Ex ritprogram. Fungerar dåligt om M uppdateras oberoende av användaren. Ex real>dsspel. Alterna>v 3: M är smart, och meddelar alla förändringar högt, utan a( veta vem (om någon) som lyssnar. OCP med hjälp av abstrak>on.

Live code Signal

Signal - status : SignalStatus - speed : Speed - view : SignalObserver + run() : void + speedup() : void + slowdown() : void - notifystatuschange() : void SignalObserver <<interface>> + actonsignalchange(signalstatus) : void SignalView + actonsignalchange(signalstatus) : void SignalApp + main(string[]) : void

:Signal :SignalView Vårt Signal object kommunicerar direkt med e7 SignalView object, som det känner ;ll.

:Signal :SignalView Vårt Signal object kommunicerar indirekt med e7 SignalView object, som det vet existerar men inte vad det är.

Mul$cas$ng A" $llåta många observers kallas ibland för mul$cas$ng informa$on om events skickas $ll mul$ple klienter. A" möjliggöra mul$cas$ng per default är en bra princip. Väldigt låg kostnad om det bara utny"jas av en klient. Följer automa$skt OCP: vi kan lä" lägga $ll fler klienter utan a" modifiera koden.

Live code SignalLogger

Signal - status : SignalStatus - speed : Speed - view : SignalObserver + run() : void + speedup() : void - slowdown() : void SignalObserver <<interface>> + actonsignalchange(signalstatus) : void SignalApp + main(string[]) : void SignalLogger + actonsignalchange(signalstatus) : void SignalView + actonsignalchange(signalstatus) : void

:Signal :SignalView :SignalLogger Vårt Signal object kommunicerar indirekt med alla lyssnare, och bryr sig inte alls om vilka de är.

Observer Pa*ern When an object needs to notify other objects of events, without directly depending on them: broadcast the events on an open channel, to which any interested object may register. DIP: Definiera e, interface enligt vilket objektet kommer a, broadcasta sina events, och låt vem som vill implementera de,a interface och registrera sig för a, lyssna. Den som lyssnar kallas observer; den som skickar events kallas observable.

Observer Pattern Observer <<interface>> + notify( ) : void Observable - observers : List<Observer> + addobserver(observer) : void + removeobserver(observer) : void - notifyobservers() : void ExternalClient class ExternalClient implements Observer { public ExternalClient(Observable t){ t.addobserver(this); } } public void notify(){ // Do something clever on callback } private void notifyobservers{ for (Observer o : observers) o.notify; }

Observer Pattern i Java I Java finns interfacen java.util.observer och java.util.observable, med de metoder vi diskuterat. Dessa är dock så väldigt enkla a< implementera själv, och vinsten med polymorfism mellan olika användningsfall är noll. Dessutom vill vi nästan all@d vara mer specifika, e.g.: Vilka events flaggas för, med vilka argument? Flaggas flera olika sorters events? Kan man registrera sig som observer för bara e<, eller alla? Mer konkreta namn än e.g. notify på metoderna hjälper läsförståelsen. Slutsats: Definiera egna varianter för era observers och observables.

Observer pa*ern i Swing Hela Java Swing är uppbyggt med hjälp av Observer Pa;ern; observers kallas Event Listeners. Alla grafiska komponenter widgets vi ritar ut med Swing kan registrera och avfyra olika events, och tar emot observers för dessa. E.g. AcIonListener, MouseListener, MouseWheelListener, FocusListener, Samma princip går igen i de flesta moderna GUI-bibliotek.

Event-driven programming Aside: Event-driven programming brukar kallas för en paradigm, dvs ett sätt att på topp-nivå strukturera program. GUI-bibliotek som Swing sägs vara instanser av event-driven programming. Vanligt vid låg-nivå-programmering, t ex operativsystem, där man hela tiden lyssnar efter olika hardware interrupts. I grunden går event-driven programming ut på att använda Observer Pattern för hela system.

Live code SpeedController

SpeedController - signal : Signal + actionperformed(actionevent e) : void Signal - status : SignalStatus - speed : Speed - view : SignalObserver + run() : void + speedup() : void - slowdown() : void SignalObserver <<interface>> + actonsignalchange(signalstatus) : void SignalApp + main(string[]) : void SignalLogger + actonsignalchange(signalstatus) : void SignalView + actonsignalchange(signalstatus) : void

Vi har en Controller Allt innanför den lila linjen är vår Model SpeedController - signal : Signal + actionperformed(actionevent e) : void Signal - status : SignalStatus - speed : Speed - view : SignalObserver + run() : void + speedup() : void - slowdown() : void SignalObserver <<interface>> + actonsignalchange(signalstatus) : void SignalApp + main(string[]) : void SignalLogger + actonsignalchange(signalstatus) : void SignalView + actonsignalchange(signalstatus) : void SignalApp tillhör varken M, V eller C - den bara initierar dessa. Den är programmet. och Vi har två en olika Controller Views.

:SignalView :SpeedController :Signal :SignalLogger Vår SpeedController styr vårt Signal object med direkt kommunika=on.

Live code Add second Signal

:SignalView :SpeedController :Signal :SignalLogger Views och Controllers behöver inte vara kopplade :ll hela modellen. Vi kan ha flera olika controllers och views för olika delar av modellen, ibland överlappande. :Signal

Översikt SignalApp En modell (M) som inte beror på något annat men som är kodad med Observer Pa;ern (OCP!), i förväntningen a; det kan komma komponenter som vill veta när den uppdateras. Flera olika vyer (V) som beror av M. Beror enbart på SignalStatus (A lägger Ill V som SignalObserver) En controller (C) som enbart beror av M men som har en grafisk widget. OBS: SpeedController kan med fördel delas upp i e.g. SpeedControlWidget (som är en dum frame med knappar) och SpeedController (som lägger Ill sig som observer hos SpeedControlWidget och hanterar knapptryckningarna). (Hem-uppgiR) Vi kan lä; lägga Ill fler controllers, som beror (enbart) på de delar av M och/eller V som de uppdaterar, eller triggas av. En applikaion (A) som skapar, sammanför och startar alla komponenter.

Slutsatser Förstå principerna för varför MVC ser ut som det gör. Extensibility, reusability, maintainability. Förstå vad som leder?ll reduk?on av beroenden. Förstå Observer PaCern och hur det hjälper?ll ac minska beroenden. Av samtliga designmönster vi kommer gå igenom är Observer PaCern det vik?gaste ac förstå. Arbeta med den struktur som ger högst cohesion och lägst coupling. Vilka beroenden som finns mellan M, V och C kan variera gör ec medvetet och ini?erat val!... förutom ac M aldrig ska bero på V och C. Punkt.

What s next Block 6-1: State och Immutability