HT1 2015, FÖRELÄSNING

Transkript

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

2 Dagens agenda Projektredovisningar denna vecka! Glöm inte 3-minuterspresentationen Layout av klassdiagram Designmönster Decorator (repetition) Model-View-Control Observer LSP Substitutionsprincipen Paketdesign Namngivning AutoArrange EDAF10/EDA061 HT2015, Ulf Asklund 2

3 Ordna manuellt Decorator - exempel StandardPayStation 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 HT2015, Ulf Asklund 3

4 Decorator - exempel <<interface>> PayStation :double StandardPayStation - sum:double :double paystation = new StandardPayStation(); TravelCard mytc = new JoJo(); 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 HT2015, Ulf Asklund 4

5 Flagga? <<interface>> PayStation StandardPayStation - sum:double - logg:boolean If logg { dologg paystation = new StandardPayStation(true); TravelCard mytc = new JoJo(); paystation.pay(mytc, 3); Flagga? <<interface>> PayStation StandardPayStation - sum:double - logg:boolean + setlogg(boolean) If logg { dologg paystation = new StandardPayStation(true); TravelCard mytc = new JoJo(); paystation.pay(mytc, 3); //med loggning paystation.setlogg(false); paystation.pay(mytc,2); //utan loggning EDAF10/EDA061 HT2015, Ulf Asklund 5

6 Subklass? <<interface>> PayStation DeLuxePayStation - sum2:double LoggedDeLuxePayStation - Logg StandardPayStation - sum:double LoggedStandardPayStation - Logg SimplePayStation - sum3:double { dologg(); super.pay(tc, zones) LoggedSimplePayStation - Logg Implementera loggningen i en subklass? Decorator! <<interface>> PayStation + pay(travelcard tc, int zones) origpaystation public double pay(travelcard travelcard, int zones) { log.add(travelcard.tostring() + zones); DeLuxePayStation StandardPayStation return origpaystation.pay(travelcard, zones); - sum:double - sum:double LoggingPayStation - Logg paystation = new StandardPayStation(); paystation.pay(mytc,3); //utan loggning paystation = new LoggingPayStation(payStation); paystation.pay(mytc, 3); //med loggning EDAF10/EDA061 HT2015, Ulf Asklund 6

7 Decorator! <<interface>> PayStation + pay(travelcard tc, int zones) origpaystation DeLuxePayStation - sum:double paystation = new StandardPayStation(); paystation.pay(mytc,4); //utan loggning paystation = new LoggingPayStation(payStation); paystation.pay(mytc, 3); //med loggning paystation = paystation.getorigps(); paystation.pay(mytc,2); //utan loggning StandardPayStation - sum:double LoggingPayStation - Logg + getorigps():paystation Decorator! <<interface>> PayStation + pay(travelcard tc, int zones) DeLuxePayStation - sum:double StandardPayStation - sum:double LoggingPayStation - PayStation - Logg 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-mönstret. EDAF10/EDA061 HT2015, Ulf Asklund 7

8 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 HT2015, Ulf Asklund 8

9 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 HT2015, Ulf Asklund 9

10 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 HT2015, Ulf Asklund 10

11 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 HT2015, 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. 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 HT2015, Ulf Asklund 12

13 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 HT2015, Ulf Asklund 13

14 Ihopkoppling av vy och modell Skapa model och vy enligt exemplet ovan: Model model = new Model(); View view = new View(model); 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); Någon nackdel? 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 HT2015, Ulf Asklund 14

15 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 HT2015, Ulf Asklund 15

16 Sekvensdiagram Anrop av en metod i modellen som ändrar dess tillstånd så att vyerna ska uppdateras. 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 HT2015, Ulf Asklund 16

17 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. 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 HT2015, Ulf Asklund 17

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

19 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 HT2015, Ulf Asklund 19

20 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 HT2015, Ulf Asklund 20

21 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. Motsvarighet: Principen om enkelt ansvar. EDAF10/EDA061 HT2015, Ulf Asklund 21

22 Reuse-release equivalence principle (REP) The granule of reuse is the granule of release Återanvä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 HT2015, Ulf Asklund 22

23 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) 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 ett cyklist beroende går inte att återanvända utan att ta med hela cykeln och allt som cykelns paket beror på. EDAF10/EDA061 HT2015, Ulf Asklund 23

24 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.*; public class B implements AI { private A a; public void method() { a.methoda(this); EDAF10/EDA061 HT2015, Ulf Asklund 24

25 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) Stabila paket skall vara abstrakta. Exempel - DIP Policy layer Mechanism Layer Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 25

26 Exempel - DIP Policy layer <<interface> Mech IF Mechanism Layer <<interface> Util IF Utility Layer Exempel - SDP Policy Policy Layer Mechanism Mechanism Layer Utility Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 26

27 Exempel - SDP Policy Policy layer Mechanism <<interface> Mech IF Mechanism Layer Utility <<interface> Util IF Utility Layer Exempel - SDP Policy Policy layer <<interface> Policy Service Mechanism Mechanism Layer <<interface> Mech Service Utility Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 27

28 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) Stabila paket skall vara abstrakta. 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 Paketets instabilitet I = 1 S = C e / (C e + C a ) I=0 är ett maximalt stabilt paket. Oberoende paket EDAF10/EDA061 HT2015, Ulf Asklund 28

29 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. 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 EDAF10/EDA061 HT2015, Ulf Asklund 29

30 Ramverk och Namngivning 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 HT2015, Ulf Asklund 30

31 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 HT2015, Ulf Asklund 31

32 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 HT2015, Ulf Asklund 32

33 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 HT2015, Ulf Asklund 33