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

Transkript

1 Objektorientering och händelsebaserad programmering Gustav Taxén Fönstersystem Applikation Interaktionstoolkit Händelsehanterare och grafiktoolkit Operativsystem Hårdvara 1

2 Frameworks Erfarenheten visar att det kan vara knepigt att hantera toolkits. Om allt är "tillåtet" är det lätt att applikationer blir inkonsekventa eller ser "fula" fula" ut. Ett framework är en uppsättning klasser (abstrakta och vanliga) som "påtvingar" ett visst sätt att arbeta. Javas framework för fönsterhantering heter Swing. Microsofts motsvarighet heter MFC (som( nu är på väg att ersättas av.net). Frameworks Koda med klassbibliotek Koda med framework Min kod Framework Kod i klassbibliotek Min kod, brukar kallas för callbacks. 2

3 Frameworks Ett vanligt sätt att arbeta med frameworks är att man subklassar någon form av basklass med grundfunktionalitet.. Sedan överlagrar man de metoder som man intresserar sig för. import java.awt.*; import javax.swing.*; public class MyFrame extends JFrame { public void paint(graphics g) { g.drawstring("hello", 10, 50); public static void main(string[] args) { MyFrame f = new MyFrame(); Inmatningstyper Request Lämna över kontrollen till användaren ndaren och vänta på att något sker. Exempel: : terminal i Unix. Sampling / polling Läsa av värdet hos en enhet så ofta som möjligt. Exempel: Spela in ljud från ljudkort 3

4 Inmatningstyper: : Events Interrupt-subrutin Inenhet Eventkö Dispatcher Systemet placerar förändringar i en kö. Beta av kön vid lämpliga tillfällen llen. Skicka en s.k. event- instans med information om varje förändring till alla callbacks som är "intresserade". Callbacklista Callback Model View Controller En design pattern för användargr ndargränssnitt. Utvecklades under sent 70-tal, bl.a. för NeXT-datorn datorn. Exempel: Flygsimulator Model - simuleringsrutiner,, etc. Controller - joystick kopplad till datorn View - vy genom cockpitfönstret 4

5 Model View Controller Model Simulering etc. Ändra roder Controller Joystick med knappar Hämta data Modifiera vyn 3D-vy View Om gränssnitten mellan de tre komponenterna inte ändras kan vilken som helst av dem bytas ut! UML Både en mjukvarudesignprocess och en serie diagramtyper. Utvecklades av företaget Rational i mitten av 90-talet. Är idag standardiserat och används nds överallt i industrin. Ger dock mycket begränsad info om hur användargr ndargränssnittetnssnittet ska se ut! 5

6 UML: Use case diagrams En abstraktion av en eller flera processer, d.v.s. ett scenario. Visar aktörer och use cases, d.v.s. vad aktörerna gör. UML: Klassdiagram 6

7 UML: Interaktionsdiagram Visar hur meddealanden skickas mellan klassinstanser i systemet. Ger en översikt över processer i systemet. UML: Tillståndsdiagram Visar hur systemet går mellan olika tillstånd nd. 7

8 UML: Aktivitetsdiagram Liknar tillståndsdiagrammet men fokuserar på aktivitet istället llet. En aktivitet behöver inte vara detsamma som ett tillstånd nd. Kan motsvara funktioner som användaren ndaren aktiverar. UML: Fysikdiagram Används nds för att visa relationen mellan hård- och mjukvara i systemet. Kan också användas ndas för att visa hur systemet är distribuerat över olika maskiner, t.ex.. i ett nätverk. 8

9 Design patterns Utgår från arkitekten Alexanders arbete på 70- talet. Alexander försökte se mönster i hur man löst återkommande problem inom arkitektur och skrev en bok där han beskriver lösningarna. Idén togs upp på allvar inom systemdesign i mitten av 90-talet. Den mest kända boken är "Design Patterns: Elements of Reusable Object-Oriented Oriented Software" av Gamma, Helm, Johnson, och Vlissides. Design patterns Namn och generell typ Intent (vad( den gör) Also Known As Motivation Applicability Structure (ett( UML-diagram) 9

10 Design patterns Participants (beskr( beskr. av klasser som ingår) Collaborations (hur( klasserna arbetar tillsammans) Consequences (av( att använda nda mönstret) Implementation Sample code Known uses Related patterns Observer Ett av de vanligaste designmönstren nstren. Tillåter att ett objekt meddelas om det gjorts en förändring i ett annat objekt, utan att objekten görs starkt knutna till varandra. 10

11 Observer Observer 11

12 Observer i Java package java.util; public interface Observer { void update(observable o, Object arg); public class Observable { private Observer[] arr; public void addobserver(observer o) { arr.addelement(o); public void notify(object arg) { for (int i = 0; i < arr.size; i++) { arr[i].update(this, arg); Det här är inte hela sanningen, men principen är densamma i den riktiga javaimplementationen! Implementering av MVC Bygger på observer-mönstret nstret. Vy-instanserna registrerar sig hos modellen. När modellen ändras anropar den update() hos vyerna. 12

13 Problem med MVC Det kan vara svårt att separera kontroller och vy i moderna grafiksystem (ta t.ex.. en slider). Men det lönar sig i princip alltid att separera datamodellen från applikationsmodellen, d.v.s. att hantera data på ett sådant sätttt att data inte är beroende av presentationen eller uppdateringen. Events i Java Påminner mycket om observer-mönstret nstret, men de som "lyssnar" måste implementera mer än en metod. Varje metod motsvarar något som hänt hos enheten. 13

14 Events i Java Events i Java package MyTests; import java.awt.*; import java.awt.event.*; public class MyFrame1 extends Frame implements WindowListener{ public void windowopened(windowevent e) { public void windowclosing(windowevent e) { System.exit(0); public void windowclosed(windowevent e) { public void windowiconified(windowevent e) { public void windowdeiconified(windowevent e) { public void windowactivated(windowevent e) { public void windowdeactivated(windowevent e) { public static void main(string [] args) { MyFrame1 frame = new MyFrame1(); frame.addwindowlistener(frame); frame.setvisible(true); 14

15 ...som inre klass package MyTests; import java.awt.*; import java.awt.event.*; class MyWindowListener implements WindowListener { public void windowopened(windowevent e) { public void windowclosing(windowevent e) { System.exit(0); public void windowclosed(windowevent e) { public void windowiconified(windowevent e) { public void windowdeiconified(windowevent e) { public void windowactivated(windowevent e) { public void windowdeactivated(windowevent e) { public class MyFrame2 extends Frame { public static void main(string [] args) { Frame frame = new MyFrame2(); frame.addwindowlistener(new MyWindowListener()); frame.setvisible(true); Adaptors Förenklar hanteringen av events. Varje adaptor implementerar ett Listener- interface, men alla metoderna är tomma. Om man subklassar en adaptor behöver man alltså bara skriva precis den kod som behövs vs. 15

16 Adaptors class MyWindowAdapter extends WindowAdapter { public void windowclosing(windowevent e) { System.exit(0); public class MyFrame3 extends Frame { public static void main(string [] args) { Frame frame = new MyFrame3(); frame.addwindowlistener(new MyWindowAdapter()); frame.setvisible(true);...eller med anonym subklass public class MyFrame4 extends Frame { public static void main(string [] args) { Frame frame = new MyFrame4(); frame.addwindowlistener(new WindowAdapter (){ public void windowclosing(windowevent e) { System.exit(0); ); frame.setvisible(true); 16

17 Java/Swing Gränssnitt i Java (och( de flesta andra GUI-system) är hierarkiska. Man börjar med en s.k. Top Level Container, och lägger till komponenter i den. Vissa komponenter är också containers och kan innehålla andra komponenter. Man specificerar dimensioner och position för varje komponent explicit eller via s.k. Layout Managers. Separable Model Architecture Varje komponent hanterar view/control. Själva utritningen är delegerad till ett s.k. UI object (för( att man ska kunna ändra look- and-feel, t.ex.)..). Varje komponent har en modell kopplad till sig. 17

18 Separable Model Architecture De flesta komponenters modell har enbart att göra med själva gränssnittet (t.ex. om en checkbutton är nedtryckt eller ej). Vissa komponenters innehåll kan dock bara definieras av applikationen (t.ex. innehållet i en lista). ). Några faller mitt emellan (t.ex.. sliders). Man ersätter en modell genom att subklassa defaultmodellen och sedan anropa setmodel() på komponenten. Separable Model Architecture Från Swings perspektiv är modellen alltså uppdelad på en mängd olika widgets. Det gör att den är svår att ersätta tta. De flesta program har en eller ett par klasser som innehåller ller hela modellen och skickar dessa värden till Swings widgets. Modellen finns alltså på två nivåer er: dels applikationsnivån, dels i varje widget. 18

19 Containers, Controls och Displays Top Level Containers: : Applet, Dialog, Frame. General-Purpose Containers: : Panel, Scroll Pane, Split Pane, Tabbed Pane, Tool Bar. Special-Purpose Containers: : Internal frame, Layered Pane, Root Pane. Basic Controls: : Buttons, Lists, Menus, etc. Uneditable Info Displays: : Label, Progress Bar, Tool Tip. Interactive Displays of Highly Formatted Information: : File Chooser, Color Chooser, etc. Top Level Containers Varje komponent kan bara befinna sig på en plats i hierarkin. Varje Top Level Component har en Content Pane som innehåller hierarkin. Man kan lägga till en menu bar (menyrad) ovanför sin content pane. 19

20 General Purpose Containers Special Purpose Containers 20

21 Basic Controls Uneditable Info Displays 21

22 Formatted Info Displays Layout Managers Det är oftast en nackdel att specificera position och dimension för komponenter explicit. Om användaren ndaren t.ex. ändrar fönstrets storlek kommer inte storleken på komponenterna att hänga med. Layout managers hjälper en att räknakna ut positioner och dimensioner dynamiskt! Man kan skapa egna layout managers. 22

23 Händelsehantering public class Beeper... implements ActionListener { // where initialization occurs: // create the button first, then: button.addactionlistener(this); public void actionperformed(actionevent e) { // Make a beep sound... 23