HT1 2013, FÖRELÄSNING 5

Transkript

1 Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061) HT1 2013, FÖRELÄSNING 5 Förra föreläsningen Projektgrupper klara?! Redovisningstid inbokad? Designmönster Strategy (exempel) Singleton Null object Facade Decorator ISP Interface Segregation Principle Muterbar vs. Ej muterbar Intro till Payroll EDAF10/EDA061 HT2013, Ulf Asklund 1

2 Dagens agenda Projektredovisningar denna vecka! Problem med Green? L Fråga från i torsdags: Decorator vs subclass Designmönster Model-View-Control Observer Paketdesign Namngivning LSP Substitutionsprincipen AutoArrange EDAF10/EDA061 HT2013, Ulf Asklund 2

3 Ordna manuellt Decorator - exempel PayStation implementerar en metod pay vilken anropas när man betalar en resa med TravelCard över ett visst antal zoner. public interface PaySation { public double pay(travelcard travelcard, int zones); public StandardPayStation implements PayStation { private double sum; public double pay(travelcard travelcard, int zones) { double price = travelcard.price(zones); sum += price; return price; EDAF10/EDA061 HT2013, Ulf Asklund 3

4 Decorator - exempel <<interface>> PayStation + pay(travelcard tc, int zones) StandardPayStation - double sum + pay(travelcard, int) paystation = new StandardPayStation(); paystation.pay(mytc, 3); Decorator-mönstret Skånetrafiken vill nu kunna logga alla köp av biljetter under oktober. Hur gör vi?? EDAF10/EDA061 HT2013, Ulf Asklund 4

5 Flagga? <<interface>> PayStation + pay(travelcard tc, int zones) StandardPayStation - double sum + pay(travelcard, int) If logg { dologg paystation = new StandardPayStation(logg); paystation.pay(mytc, 3); Subklass? <<interface>> PayStation + pay(travelcard tc, int zones) DeLuxePayStation - double sum + pay(travelcard, int) StandardPayStation - double sum + pay(travelcard, int) SimplePayStation - double sum + pay(travelcard, int) LoggedStandardPayStation - double sum - Logg + pay(travelcard, int) Implementera loggningen i en subklass? EDAF10/EDA061 HT2013, Ulf Asklund 5

6 Decorator! <<interface>> PayStation + pay(travelcard tc, int zones) DeLuxePayStation - double sum + pay(travelcard, int) StandardPayStation - double sum + pay(travelcard, int) LoggingPayStation - PayStation - Logg + pay(travelcard, int) standardpaystation = new StandardPayStation(); paystation = new LoggingPayStation(standardPayStation); paystation.pay(mytc, 3); Decorator! <<interface>> PayStation + pay(travelcard tc, int zones) DeLuxePayStation - double sum + pay(travelcard, int) StandardPayStation - double sum + pay(travelcard, int) LoggingPayStation - PayStation - Logg + pay(travelcard, int) Endast en Decorator även om det finns många subklasser till PayStation Tillståndet i StandardPayStation bevaras Multipla Decorators? Se kap. 28 i Martin Visitor. EDAF10/EDA061 HT2013, Ulf Asklund 6

7 Decorator-mönstret Den nya funktionaliteten: public LoggingPayStation implements PayStation { private PayStation paystation; private List<String> log; public LoggingPayStation(PayStation paystation, List<String> log) { this.paystation = paystation; this.log = log; public double pay(travelcard travelcard, int zones) { log.add(travelcard.tostring() + zones); return paystation.pay(travelcard, zones); Loggningen kan göras dynamiskt PayStation standardpaystation = new StandardPayStation(); PayStation paystation = standardpaystation; I början av oktober lägger vi till loggningen: paystation = new LoggingPayStation(standardPayStation); I slutet av oktober tar vi bort den: paystation = standardpaystation; Tillståndet i standardpaystation bevaras. EDAF10/EDA061 HT2013, Ulf Asklund 7

8 Model/View/Control Model/View/Control-arkitektur Modellen beskriver systemets tillstånd. Vyn visar upp systemets tillstånd. Control förändrar systemets tillstånd. View Model Control EDAF10/EDA061 HT2013, Ulf Asklund 8

9 Model/View/Control-implementering JFrame <<interface>> ActionListener JButton View Model Control Paketberoenden View Model Control Model/View/Control Varför? Principen om enkelt ansvar. Integritet: Modellen behöver inte känna till vyn. Flera vyer av en modell. Om Control saknar tillstånd slår vi ofta ihop vyn och control till ett grafiskt användargränssnitt, GUI. EDAF10/EDA061 HT2013, Ulf Asklund 9

10 Observer Observer-mönstret används för att separera modellen från användargränssnittet, vyn. Vyn implementerar gränssnittet Observer. Modellen utvidgar klassen Observable. När modellens tillstånd förändras informeras alla observatörer om att det skett en förändring och vyerna uppdaterar sig genom att hämta information från modellen. Observer/Observable är ett ramverk; klasserna finns färdiga. Observer & Observable Finns i java.util public class Observable { public void addobserver(observer observer) public void deleteobserver(observer observer) protected void setchanged() public void notifyobservers(object object) public void notifyobservers() // omissions public interface Observer { public void update(observable observable, Object object); EDAF10/EDA061 HT2013, Ulf Asklund 10

11 Observer-mönstret Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. Observer-mönstret public class Model extends Observable { private int state; public void changestate() { state++; setchanged(); notifyobservers(); public String state() { return String.valueOf(state); Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. EDAF10/EDA061 HT2013, Ulf Asklund 11

12 Observer-mönstret Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. public class View extends JLabel implements Observer { private Model model; public View(Model model) { this.model = model; model.addobserver(this); public void update(observable observable, Object object) { settext(model.state()); Tydlig koppling till modellen. Observer-mönstret public class View extends JLabel implements Observer { public View(Model model) { model.addobserver(this); public void update(observable observable, Object object) { Model model = (Model) observable; settext(model.state()); Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. Mindre tydlig koppling till modellen. EDAF10/EDA061 HT2013, Ulf Asklund 12

13 Extern ihopkoppling Kopplingen mellan vy och modell kan också göras där vy och modell skapas: Model model = new Model(); View view = new View(); model.addobserver(view); public class View extends JLabel implements Observer { public void update(observable observable, Object object) { settext(observable.tostring()); Java.util.Observable implementering public class Observable { private boolean changed = false; private Vector<Observer> vector = new Vector<Observer>(); public synchronized void addobserver(observer observer) { if (!vector.contains(observer)) { vector.add(observer); protected synchronized void setchanged() { changed = true;... EDAF10/EDA061 HT2013, Ulf Asklund 13

14 java.util.observable Något förenklad: public class Observable { private boolean changed = false; private Vector<Observer> vector = new Vector<Observer>(); public void notifyobservers() { notifyobservers(null); public synchronized void notifyobservers(object arg) { if (!changed) { return; changed = false; for (Observer observer: vector) { observer.update(this, arg); MVC med Observer En eller flera vyer registrerar sig som observatörer av modellen via addobserver. OCP Open-Closed Principle Ett kommando modifierar modellens tillstånd. Modellen informerar Observable att tillståndet förändrats via setchanged. Modellen begär att observatörerna informeras genom notifyobservers. notifyobservers i Observable informerar observatörerna via update om att modellen förändrats. Observatörerna hämtar modellens nya tillstånd och uppdaterar vyerna. EDAF10/EDA061 HT2013, Ulf Asklund 14

15 Sekvensdiagram Observer, update-parametrarna public interface Observer { public void update(observable observable, Object object); När man anropar notifyobservers(object) i modellen kommer update(observable, Object) att anropas i alla observatörer. Vad skall man använda argumenten till? EDAF10/EDA061 HT2013, Ulf Asklund 15

16 Update(observable, ) Observable kan användas för att komma åt modellen. Det är tydligare att ge observatören tillgång till modellen via observatörens konstruerare. Det kan vara praktiskt att anropa addobserver i observatörens konstruerare. Update(, object) Object kan användas för att skicka information från modellen till vyn. Fråga: Hur kan modellen veta vad vyn vill ha? Svar: Det kan den inte veta. Fråga: Det kan finnas flera observatörer som vill veta olika saker. Hur skall informationen förpackas? Svar: Det är svårt att veta om man inte känner till alla observatörer som kan vara aktuella. Det finns ingen naturlig plats att dokumentera förpackningen. EDAF10/EDA061 HT2013, Ulf Asklund 16

17 Designprincip för Observer.update Undvik att använda parametrarna. LSP Liskov Substitution Principle EDAF10/EDA061 HT2013, Ulf Asklund 17

18 LSP Substitutionsprincipen Liskov Substitution Principle Subtypes must be substitutable for their base types. När man konstruerar en subklass till en superklass så skall man göra det så att alla metoder som har superklassen som parametertyp även fungerar när argumentet är en instans av subklassen. Exempel: Model ersätter Observable, View ersätter Observer. Brott mot LSP public class IntPair { private int i1, i2; public boolean equals(object object) { IntPair other = (IntPair) object; return i1==other.i1 && i2==other.i2; IntPairär en subklass till Object. Den bryter mot LSP på två sätt: Metoden kastar ett undantag om object har fel typ. Den borde returnera false när detta händer. Klassen fungerar ej som nyckel i en hashtabell. Lika objekt skall ha samma hashkod. EDAF10/EDA061 HT2013, Ulf Asklund 18

19 Reparation av IntPair public final class IntPair { private int i1, i2; public int hashcode() { return i * i2; public boolean equals(object object) { if(object instanceof IntPair) { IntPair other = (IntPair) object; return i1==other.i1 && i2==other.i2; return false; Paketdesign Martin, kapitel 20 och 22 EDAF10/EDA061 HT2013, Ulf Asklund 19

20 Designprinciper för paket Sammanhangsprinciper (package cohesion) Common reuse principle (CRP) Reuse-release equivalence principle (REP) Common closure principle (CCP) Stabilitetsprinciper (package coupling) Acyclic dependencies principle (ADP) Stable dependencies principle (SDP) Stable abstractions principle (SAP) Common reuse principle (CRP) Klasserna i paketet är så nära relaterade att om man behöver en av dem så behövs i regel även de övriga. Exempel: Mjukvarupaketet i Computer. Om man behöver en instruktion så behövs också de andra instruktionerna och Program-klassen. Motsvarighet: Principen om enkelt ansvar. EDAF10/EDA061 HT2013, Ulf Asklund 20

21 Reuse-release equivalence principle (REP) The granule of reuse is the granule of release Ateranvändning (reuse) innebär att det är paketägaren som underhåller och ger ut (release) paketet. Den som använder paketet skall inte behöva ändra på paketet och inte behöva titta på implementeringen och bestämmer själv när en ny utgåva skall integreras. Exempel: När hårdvarugruppen i det stora Computerprojektet kommer med en ny version av hårdvaran så kan simuleringsgruppen själv bestämma när den skall uppgradera hårdvaran och kan göra det utan att titta på implementeringen. Motsvarighet: Lokalitets- och integritetsprinciperna Common closure principle (CCP) Klasserna i ett paket skall vara stängda resp. öppna tillsammans gentemot samma slags förändringar. Förändringar som påverkar en klass i paketet får påverka andra klasser i paketet men inga klasser utanför paketet. Exempel: När vi vill introducera VeryLongWord i Computerprojektet skall man bara behöva ändra i hårdvarupaketet. Motsvarighet: öppen/sluten-principen. Single-responsibility principen. EDAF10/EDA061 HT2013, Ulf Asklund 21

22 Stabilitetsprinciper Paket skall ej vara cykliskt beroende. Beroenden skall gå mot stabila paket. Stabila paket skall vara abstrakta. Cykelproblem Paketstrukturen kan inte byggas top down inte det första man gör i sin systemdesign. Ett paket som ingår i en cykel går inte att återanvända utan att ta med hela cykeln och allt som cykelns paket beror på. EDAF10/EDA061 HT2013, Ulf Asklund 22

23 Med cykel package a; import b.b; public class A { public void methoda(b b) { b.method(); package b; import a.a; public class B { private A a; public void method() { a.methoda(this); Utan cykel package a; public interface AI { public void method(); public class A { public void methoda(ai ai) { ai.method(); package b; import a.a; public class B implements AI { private A a; public void method() { a.methoda(this); EDAF10/EDA061 HT2013, Ulf Asklund 23

24 Stabilitetsmetrik Paketets stabilitet S = C a / (C e + C a ), där C a är antalet klasser utanför paketet som beror på klasser i paketet. a står för afferent (inåtriktad). C e är antalet klasser i paketet som beror på klasser utanför paketet. e står för efferent (utåtriktad). S=0 innebär inget ansvar S=1 innebär inget beroende Om S=1 för alla paket i systemet så är det inget system. Paketets instabilitet I = 1 S = C e / (C e + C a ) I=0 är ett maximalt stabilt paket. Oberoende paket Stabilitetsmetrik Paketets Abstrakthet A = N a / N c, där N a är antalet abstrakta klasser (gränssnitt) i paketet. N c är antalet klasser i paketet. EDAF10/EDA061 HT2013, Ulf Asklund 24

25 A-I grafen A = I = 1 är meningslösa zonen (useless zone) A = I = 0 är problemzonen (zone of pain) A = 0, I =1 och A = 1, I = 0 är önskvärda zoner Paketstrukturer Komponenter Paketen är komponenter i systemet. Exempel: memory och program i Computer. Ramverk Systemet byggs genom att utvidga klasser i andra paket. Exempel: javax.swing, java.awt. Ett användargränssnitt konstrueras genom att utvidga och fylla i klasserna i ramverket. Eclipse. Observer/Observable EDAF10/EDA061 HT2013, Ulf Asklund 25

26 Ramverk Ramverk är mycket svårare att bygga. You have to build at least three frameworks and reject them before you can be reasonably confident that you have build the right archictecture for one domain. [Paraphrasing Rebecca Wirfs-Brock.] Martin: Kapitel 30. Educational Testing Service. Namngivning Bra namngivning är fundamental för att göra program begripliga. public class MyList { private List<int[]> thelist; public List<int[]> getlist() { List<int[]> list = new ArrayList<int[]>(); for (int[] is : thelist) { if (is[0] < 4) { list.add(is); return list; Vad handlar det om? EDAF10/EDA061 HT2013, Ulf Asklund 26

27 Det handlar om projektgrupper I vilka grupper finns det plats för ytterligare studenter? public class Groups { private List<Group> groups; public List<Group> incompletegroups() { List<Group> list = new ArrayList<Group>(); for (Group group : groups) { if (! group.iscomplete()) { list.add(group); return list; En grupp ska bestå av fyra studenter public class Group extends ArrayList<Student> { private static final int MAXSIZE = 4; public boolean iscomplete() { return size() >= MAXSIZE; EDAF10/EDA061 HT2013, Ulf Asklund 27

28 Dokumentation av MyList De reviderade klasserna behöver knappast någon särskild dokumentation. MyList gör det: MyList innehåller en lista av grupper av studenter. En grupp representeras med en heltalsarray där det första elementet innehåller antalet studenter i gruppen och de övriga innehåller id-nummer för studenterna. Metoden getlist returnerar en lista med de grupper som har plats för ytterligare studenter. EDAF10/EDA061 HT2013, Ulf Asklund 28