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

Transkript

1 TDDC30 Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Designmönster Adapter, Factory, Iterator, Observer Singleton, MVC, Strategy Antimönster 1

2 Vart började vi? Ada gav oss funktioner, datastrukturer och paket.. function sum(a, b : in Integer) return Integer is begin return a + b; end sum; package body Package_Name is end Package_Name; 2

3 Vad lades till? Java byggde på med: Objektorientering Arv Polymorfi Klassmetoder Klassvariabler Klass Beskrivs av Instantierar Objekt Instansmetoder Instansvariabler 3

4 Ett naturligt följdsteg.. Abstrakt datatyp En datatyp där man bortser från implementationsspecifika egenskaper och istället uppmärksammar en eller några få egenskaper. ADT implementeras med lämpliga datastrukturer och algoritmer Abstraktion (subst.) En tankeprocess i vilken man bortser från vissa egenskaper hos en företeelse eller ett föremål och i stället uppmärksammar en eller några få egenskaper Källa: Nationalencyklopedin (förkortad form) Vad händer om vi tar abstraktion ett steg längre..? 4

5 Designmönster Design: Att tillgodose ej förhandlingsbara krav samt optimera de förhandlingsbara Mönster: Regelbundenhet, något som upprepar sig Designmönster: Kärnan till en lösning på ett vanligt förekommande problem Objektorientering för återanvändning av kod, designmönster för återanvändning av lösningar 5

6 Scenario Anna skriver ett program och behöver en specifik funktionalitet Hon börjar med att skapa en klass med tomma metoder och använder sedan dessa som om de var implementerade så länge Harry berättar att han implementerade något liknande i ett annat projekt. Anna får gärna använda hans lösning, bara hon inte ändrar något i koden Harrys metoder ser inte riktigt likadana ut som Annas men kan uträtta samma uppgifter 6

7 Lösning vilket designmönster? Koden för lösningen: class AnnasClass { int makeitso(string data) {...} } class HarrysClass { int doit(int times, String info) {...} } Mönster: Få klasser som annars är class AnnasAdapter extends AnnasClass { private HarrysClass adaptee = int makeitso(string data) { return adaptee.doit(1, data); } } inkompatibla att jobba tillsammans Adapter Design Pattern! 7

8 Vilket designmönster? Avsikt: Tillhandahålla ett gränssnitt för att skapa familjer av liknande eller beroende objekt utan att specificera deras konkreta klasser. Motivering: Skapandet av ett objekt kan vara en komplex process som inte bör ligga hos den som sedan hanterar objektet. Valet av vilket objekt som ska skapas kan vara svårbestämt, och kan ändras ofta. 8

9 Designmönstret Factory Tillämpning: Använd när En klass inte kan förutse vilken klass som ska instantieras En klass vill att dess subklasser ska specificera klassen som instantieras Skapandet av objekt är för komplext för konstruktorer 9

10 Vilket designmönster? Avsikt: Komma åt element i en objeksamling utan att synliggöra den underliggande representationen. Motivering: Traversera samlingen på olika sätt, baklänges, filtrera Flera samtidiga traverseringar Det är omständigt att låta samlingen själv innehålla traverseringsmetoder Struligt att behöva skriva särskild kod för att traversera olika typer av samlingar 10

11 Designmönstret Iterator Tillämpning: Dölj den inre representationen Stöd flera typer av traverseringar Enhetligt sätt att traversera samlingsstrukturer 11

12 Vilket designmönster? Avsikt: Definiera en "en till många"-relation mellan objekt, sådant att när ett objekt ändrar tillstånd meddelas alla beroende objekt Motivering: Svårt att hålla nära beroende objekt i synk Man vill inte påverka återanvändbarheten => Lös, detaljoberoende koppling 12

13 Designmönstret Observer Tillämpning: Använd när En abstraktion har flera aspekter, den ena beroende av den andra När en händelse i ett objekt kräver aktion i andra, och det är svårt att uppskatta exakt vilka andra När ett objekt behöver meddela intresserade om att något hänt 13

14 Vilket designmönster? Avsikt: Försäkra sig om att en klass bara har en enda instans och att det finns en global tillgång till denna. Motivering: I somliga program ska en klass bara instantieras en gång. Till exempel kan det finnas många skrivare i ett system, men bara en skrivarkö. 14

15 Designmönstret Singleton Tillämpning: Använd när Det bara får finnas en instans av en klass, som måste vara tillgänglig för hela programmet. Denna instans ska gå att utöka m.h.a. subklassning Obs: Använd bara med goda skäl.. 15

16 Vilket designmönster? Avsikt: Ge möjligheten att byta beteende under programmets körning, genom att t.ex. byta den algoritm som används för att lösa ett problem. Motivering: Ibland är vissa lösnings-strategier bättre för vissa typer av problem, samtidigt som andra varianter av samma problem kan lösas bättre av andra algoritmer. 16

17 Designmönstret Strategy Tillämpning: Använd när Flera olika lösningsstrategier är tillgängliga Det ska gå att byta fritt mellan olika lösningsstrategier Alla lösningar kan arbeta med samma modell 17

18 Vilket designmönster? Avsikt: Dela upp de övergripande ansvarsområdena för programkod inom ett avancerat, grafiskt program. Motivering: Ju större ett program blir, desto större blir behovet av en konsistent, lättbegriplig struktur som är lätt att följa och modifiera. 18

19 Designmönstret MVC MVC Model View Controller Tillämpning: Använd när Ett program kan delas upp i: Model Datastrukturen och de algoritmer som hör till View Utritningen Controller Tar input från vyn och översätter den till operationer på modellen 19

20 Antimönster En programmerare utvecklar inte bara goda vanor. En del dåliga mönster antimönster, dyker upp ibland Spaghetti code Hoppig kod utan överskådlig struktur God object En klass som fått alltför mycket ansvar, växt sig för stor Ofta ett symptom på bristande objektorientering eller för mycket global variabel-tänk Object orgy Bristande inkapsling leder till att objekts beteende blir oförutsägbart Klassens kontrakt kan inte längre garanteras Fler? Se (kom ihåg, allt är inte sant på internet) 20

21 Antimönster (2) Repeating yourself Samma kodstycke dyker upp på flera platser i programmet Motsatsen till principen Don t Repat Yourself (DRY) Programming by permutation Problem löses genom att skriva kod och se om det funkar Ofta ett symptom på att man inte är nog insatt i koden eller problemet Premature optimization Enkel och elegant design offras för att istället optimera We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil Donald Knuth 21

22 Vad mer kan vi hitta på..? + =? 22