Objektkonstruktion. Vilka sorter finns? Varför ärver vi? Aggregering ger en lösare koppling till delarna än komposition. 1nJUDÃJUXQGOlJJDQGHÃUHJOHU

Transkript

1 'HVLJQDYREMHNW 6HSWHPEHUÃÃ +XUÃVNDSDUÃYLÃREMHNWÃRFKÃNODVVHU" 1nJUDÃJUXQGOlJJDQGHÃUHJOHU %M UQÃ(LGHUElFN 1$'$Ã.7+ (PDLOÃEMRUQH#QDGDNWKVH Innehåll Arv eller komposition/aggregering Cohesion och coupling Några mönster för att designa system Ett par tekniker för att identifiera klasser och attribut Vad är trenden då man bygger system idag?, F7 $JJUHJHULQJHOOHUNRPSRVLWLRQ Aggregering ger en lösare koppling till delarna än komposition Vid komposition försvinner delarna också om den som använder dem försvinner Vad är bäst aggregering eller komposition? Det beror återigen på Om man tex har en Person så kan denna samtidigt finnas i både ett telefonlist och en lista av låntagare på ett bibliotek Då vill vi att personen ska finnas kvar även om respektive lista rensas previous next previous next 4, F7 $UYHOOHUDJJUHJHULQJ" Vad är att föredra arv eller aggregering? Tumregeln är att använda arv om: Den nya klassen är en subtyp till en existerande, är-en Cirkel är en ellips Båt är en farkost För snabba prototyper, F7 $UY Arv är fundamentalt i objektorienterad programmering För att ett språk skall kallas objektorienterat så måste arv ingå som en möjlig väg att återanvända kod och beskrivningar I programspråksammanhang låter vi VXENODVVHU ärva både struktur och attribut från VXSHUNODVVHU dvs både variabler och metoder ärvs A 6KDSH position : Point bounds() :Rectangle draw() : void extent() : Point Annars bör man nog i första hand försöka med aggregering En personlista kan byggas mha av aggregering med hjälp av en Vector eller Collection (tex ArrayList) B E C D 6KDSH extent : Point draw() : void 6KDSH extent : Point draw() : void previous next 2 previous next 5, F7 $UY Vilka sorter finns? Varför ärver vi?, F7 DUY Arv kan delas in i två huvudtyper Arv för specifikation dvs arv av protokoll Arv av kod dvs arv av beteende och struktur Arv kan vara av olika typ Generalisering (eng. extension) subklassen är rikare än, eller en utvidgning av, superklassen Specialisering (eng. specialisation) subklassen är mer specialiserad än, eller ett specialfall av, superklassen Arv är transitivt Om A superklass till B och B superklass till C så ärver C attribut och beteende från både B och A previous next 3 previous next 6 %M UQ(LGHUElFN 1

2 , F7 Boolean Byte -DYDVEDVNODVV2EMHFW Klassen Object är överst i Javas klassträd Number Integer String 2EMHFW equals(obj : Object) : boolean tostring() : String getclass() : String Graphics Klassen Object med några subklasser och några viktiga metoder Component Button Label Container, F7 Arv för utvidgning Subklassen lägger till ny funktionalitet i förhållande till superklassen men förändrar inte existerande beteende En Egenskapslista kan implementeras genom att utvidga en HashTable (en hashad tabell med nyckel/värde-par) Arv för begränsning Subklassen inskränker superklassens beteende En MängdKlass kan implementeras som en "inskränkt" Vector Arv för kombination Subklassen ärver från mer än en superklass En Amfibiebil kan implementeras genom att kombinera en Bil med en Båt Window Panel previous next 7 previous next 10, F7 6XENODVVVXEW\SRFKHUVlWWEDUKHW Abstrakt datatyp Är en inkapsling av data och dom metoder som opererar på dessa data Subtyp En viss typ A är VXEW\S till en annan typ B omm A åtminstone erbjuder samma beteende som B och att A kan användas överallt där B kan användas utan att någon skillnad kan observeras Subklass En subklass ärver struktur och beteende från sina superklasser En subklass kan berika, inskränka eller förändra det ärvda beteendet från sina superklasser Ersättbarhet Ett objekt av typ A som är subtyp till typen B kan användas som om det vore av typ B eftersom det åtminstone uppvisar B:s beteende, F7 ([HPSHOROLNDW\SHUDYDUY Arv för specialisering Ellipse Circle Arv för specifikation Win95Window tank engine wheels() speed() Window MotorLandVehicle MacWindow Car Bike Lorry MotorCycle previous next 8 previous next 11, F7 2OLNDIRUPHUDYDUY Arv för specialisering subklassen är ett specialfall av superklassen, dvs subklassen är en subtyp till superklassen En Tandemcykel är en speciell sorts Cykel Arv för specifikation Superklassen specificerar beteende som inte är implementerat i superklassen men måste implementeras i dess subklasser Ett Fordon specificerar en Bil och Cykel Arv för konstruktion Subklassen utnyttjar superklassens beteende men är inte subtyp till superklassen En FigurGrupp kan implementeras mha av en Vector, F7 Arv för konstruktion Arv för utvidgning Arv för begränsning Polyline Vector Circle Vector Cartoon Stack Ellipse Set Arv för kombination Collection GraphicObject Car Boat GraphicComponent AmfibieCar previous next 9 previous next 12 %M UQ(LGHUElFN 2

3 , F7, F7 ) UGHODUPHGDUY 0HNDQLVPHUI UnWHUDQYlQGQLQJDYPMXNYDUD Återanvändning av mjukvara Enkelt att modifiera passande klass (på ett strukturerat sätt) Ökad tillförlitlighet Klasser i "bibliotek" som används av många blir hela tiden testade Delande av kod Likartade komponenter kan dela (stora delar) kod som kan beskrivas i gemensam superklass Överenstämmande gränssnitt Klasser som ärver från gemensam superklass överenstämmer troligare än om dom ärver från separata grenar Ersättbarhet Vi strävar efter att skriva programvara där vissa komponenter kan ersättas av andra utan att påverka några andra delar av systemet Är-en eller har-en Ofta användbar tumregel: använd arv då en komponent är-en (specialisering) av någon annan en tandemcykel är-en cykel, en bil är-ett fordon, en student är-en person använd komposition då en komponent har-en annan komponent som en av sina delar en bil har-en motor, en människa har-en vän Arv av kod eller arv av beteende Arv av gemensam klass bör väljas då kod och struktur delas Ett gränssnitt bör delas då specifikation av beteende men inte den egentliga koden delas previous next 13 previous next 16, F7, F7 RPSRVLWLRQHOOHUDUY Klassen Vector ser förenklat ut på följande sätt: class Vector{ public boolean isempty() {... public int size() {... public void addelement(object value) {... public Object lastelement() {... public Object removeelementat(int index) { Nu kan vi konstruera en stack genom att utnyttja Vector med Mjukvarukomponenter Arv gör det enkelt att konstruera återanvändbara komponenter Snabb konstruktion av prototyper Ofta snabbt att återanvända klasser och endast ändra det som skiljer Polymorfi och frameworks Genom polymorfi och arv är det relativt enkelt att beskriva systemstruktur och beteende på hög nivå vars detaljer sedan kan beskrivas av användarnas konkreta subklasser Inkapsling av information Ofta tillräckligt att känna till superklassens protokoll utan detaljer om dess implementation.rpsrvlwlrq $UY previous next 14 previous next 17, F7, F7 RVWQDGHUI UDUY Exekveringshastighet Viss extra kostnad för metoduppslagning Programstorlek Programbibliotek ger ofta mer binärkod än specialdesignade klasser Programkomplexitet Kod skriven med djupa arvshierarkier ger ofta komplexa strukturer med svårgripbara programflöden Jo-Jo-problemet: där metoder än i superklasser än i subklasser används om vartannat NRPSRVLWLRQ 6WDFN isempty() : boolean push(v : Object) : void peek(): Object pop() : Object Stack() : Stack data 9HFWRU previous next 15 previous next 18 %M UQ(LGHUElFN 3

4 , F7, F7 NRPSRVLWLRQ $UYHOOHUNRPSRVLWLRQ" class Stack{ SURWHFWHGÃ9HFWRUÃGDWD public Stack() {GDWD = new Vector(); public boolean isempty() {return GDWD.isEmpty(); public void push(object v) {GDWD.addElement(v); public Object peek() {return GDWD.lastElement(); public Object pop(){ Object result = peek(); GDWD.removeElementAt(GDWD.size() - 1); return result; Arv ger implicit (eller explicit) antagande om ersättbarhet Subklasser antas vara subtyper Detta "antagande" gäller inte för komposition Komposition är enklare än arv Komposition anger mer tydligt vilka operationer som kan tillämpas på en viss klass Vid arv är subklassernas mängd av operationer en supermängd av superklassens mängd av operationer Programmeraren måste undersöka superklassen för att ta reda på vilka operationer som är legala för subklassen Arv ger kortare beskrivningar än komposition Arv förhindrar inte manipulation av den nya strukturen via ("illegala") operationer i superklassen previous next 19 previous next 22, F7, F7 DUY 9HFWRU Komposition döljer implementationsdetaljer mer än vad arv gör Det är enkelt att ersätta en viss struktur med en annan En stack kan använda en vektor, byta till en länkad lista eller använda sig av en databas 6WDFN Vid arv har subklasser tillgång till alla icke privata fält i superklassen medan man vid komposition endast har tillgång till publika fält push(v : Object) : void peek(): Object pop() : Object Arv låter oss använda den nya abstraktionen som argument i en polymorf funktion previous next 20 previous next 23, F7, F7 DUY class 6WDFNÃH[WHQGVÃ9HFWRU{ public void push(object v) {addelement(v); public Object peek() {return lastelement(); public Object pop(){ Object result = peek(); removeelementat(size() - 1); return result; Vid arv får vi kortare kod än vid komposition. Därmed blir koden mer överskådlig. Å andra sidan är gränssnittet mer tydligt vid komposition Vid arv måste man fråga sig: Vilka delar av den ärvda koden är tänkt att användas? Vilka delar är nödvändiga eller riskabla att initiera respektive förändra? En implementation med arv har en liten fördel i exekveringstid Ett extra funktionsanrop behövs vid komposition previous next 21 previous next 24 %M UQ(LGHUElFN 4

5 , F7, F7 &RKHVLRQ När man pratar om cohesion pratar man om hur sammanhållen i viss komponent, eller ett antal komponenter i ett system, är. Med hög cohesion menas att komponenten gör ett väldefinierat sammahållet arbete.diihnrnduqãeu\jjhuãndiihãphqãvnlfnduãlqwhãid[ 1nJRWRPGHVLJQP QVWHU Ett designmönster beskriver lösningar på ett sätt så att mönstret kan användas i olika (snarlika) situationer Å(DFKÃSDWWHUQÃGHVFULEHVÃDÃSUREOHPÃZKLFKÃRFFXUVÃRYHUÃDQGÃRYHUÃDJDLQÃLQÃRXUÃ HQYLURQPHQWÃDQGÃWKHQÃGHVFULEHVÃWKHÃFRUHÃRIÃWKHÃVROXWLRQÃWRÃWKDW SUREOHPÃLQÃ VXFKÃDÃZD\ÃWKDWÃ\RXÃFDQÃXVHÃWKLVÃVROXWLRQÃDÃPLOOLRQÃWLPHVÃRYHUÃZLWKRXWÃHYHUÃ GRLQJÃLWÃWKHÃVDPHÃWZLFHÃÅ &KULVWRSKHUÃ$OH[DQGHUÃ Å$ÃGHVLJQÃSDWWHUQÃVLPSO\ÃFDSWXUHVÃWKHÃVDOLHQWÃFKDUDFWHULVWLFVÃÃRIÃDÃVROXWLRQÃWRÃD SUREOHPÃWKDWÃKDVÃEHHQÃREVHUYHGÃWRÃRFFXUÃUHSHDWHGO\ÃLQÃPDQ\ÃGLIIHUHQWÃSUREOHPÃ GRPDLQVÅ %XGGÃ Å$ÃGHVLJQÃSDWWHUQ SURYLGHVÃDÃVFKHPHÃIRUÃUHILQLQJÃWKHÃVXEV\VWHPVÃRUÃFRPSRQHQWVÃRIÃ DÃVRIWZDUHÃV\VWHPÃRUÃWKHÃUHODWLRQVKLSVÃEHWZHHQÃWKHPÃ,WÃGHVFULEHVÃDÃFRPPRQO\Ã UHFXUULQJÃVWUXFWXUHÃRIÃFRPPXQLFDWLQJÃFRPSRQHQWVÃWKDWÃVROYHVÃDÃJHQHUDOÃGHVLJQÃ SUREOHPÃZLWKLQÃDÃSDUWLFXODUÃFRQWH[WÅÃ*DPPDÃÉÃFRÃ previous next 25 previous next 28, F7 &RXSOLQJ Med coupling menas hur mycket olika komponenter beror av, eller är relaterade till, varandra, F7 9DUI UGHVLJQP QVWHU" 'RPÃHUEMXGHUÃH[SHUWNXQVNDS Man strävar efter att bygga system med så lite coupling mellan komponenterna som möjligt 'RPÃJHUÃRVVÃHQÃNUDIWIXOOÃYRNDEXOlU 9LÃI UVWnUÃSURJUDPV\VWHPÃVQDEEDUH RPÃGRPÃlUÃGRNXPHQWHUDGHÃ En strävan är att om ett objekt ändras så ska så få andra objekt som möjligt påverkas PHGÃGHVLJQP QVWHU 'RPÃI UHQNODUÃRPVWUXNWXUHULQJ DYÃV\VWHPÃXQGHUKnOO previous next 26 previous next 29, F7 *HQHUHOODNRGQLQJVUHJOHUHWWXUYDO Välj klass-, attribut- och metodnamn med omsorg Ingen duplicerad kod Skriv korta metoder (typiskt max fem rader kod per metod) Långa metoder är en signal till att något är fel och refactoring behövs Undvik case-satser Undvik villkorsatser (fundera åtminstone först...) Programmera mot interface Om det inte är en subtyp fundera på aggregering innan arv Fast då det är naturligt, vid prototyping eller om det redan finns färdiga klasser kan arv vara bäst Använd om möjligt Interface som typ (för parametrar, variabler, etc) previous next 27, F7 *5$63 I Larman diskuteras objektdesign i form av en uppsättning mönster General Responsibility Assignment Software Patterns (GRASP) previous next 30 %M UQ(LGHUElFN 5

6 , F7, F7 1nJUDP QVWHUIUnQ*5$63 Expert Creator /RZ&RXSOLQJ Hur bygger man ett system med där komponenterna inte är strakt beroende av varandra, förändringar i en del så lite som möjligt påverkar varandra och gör det möjligt att återanvänds så mycket som möjligt? Low Coupling High Cohesion Tilldela ansvar så att beroendet mellan objekten, kunskapen ett visst objekt har om (det inre av) ett annat är så liten som möjligt, dvs coupling är så liten som möjligt Se Larman 16.8 previous next 31 previous next 34, F7, F7 ([SHUW +LJK&RKHVLRQ Hur tilldelar man ansvar till objekt? Hur gör man systemets komplexitet så hanterbar som möjligt? Tilldela ansvaret till informationsexperten, dvs den klass som har nödvändig informationen för att lösa problemet Tilldela ansvar [åt klasserna] så att cohesionen blir så hög som möjligt. Dvs en klass/objekt skall helst bara göra en sak. Se Larman 16.6 Se Larman 16.9 previous next 32 previous next 35, F7, F7 &UHDWRU Vem ansvarar för att skapa nya instanser av en viss klass? Ge klassen B ansvaret för att skapa instanser av klassen A om: B aggregerar A-objekt B innehåller A-objekt B bokför instanser av A B använder A-objekt B har dom data som behövs för att initera A (B är en Expert i förhållande till A) 0RGXOlU'HVLJQ Redan innan objektorienterad programmering försökte man dela in ett system på olika moduler eller paket som gjorde (väldefinierat) olika saker Se Larman 16.7 previous next 33 previous next 36 %M UQ(LGHUElFN 6

7 , F7, F7 0 QVWUHW&RQWUROOHU Från 70-talsmönstret Model View Controller (MVC) (WWÃDQQDWÃVlWWÃlUÃ:LUIV%URFNVÃQRPLQDOIUDVVWUDWHJL Läs och förstå kravdokumentet. Målet är att hitta en modell som väl avspeglar den aktuella problemdomänen Grundidén är att separera logik, kontroll och presentation från varandra Läs igenom dokumentet igen. Titta speciellt efter nominalfraser. Skapa en preliminär lista av dessa fraser och ändra alla plural till singular Vi vill alltså att ett visst objekt ansvarar för kontrollen, dvs tar hand om händelser, tex från mus och tangentbord Dela nominalfraserna i tre kategorier: definitivt objekt, nonsensobjekt och möjliga objekt MVC är också pappa till massa andra mönster Två av dom mest kända är Observer Factory method CRC-kort previous next 37 Strunta i nonsenobjekten Diskutera "möjliga objekt" och placera vart ett av dom i någon av dom andra två kategorierna previous next 40, F7, F7 Vy Visualisera modellen Transformera koordinater Kontroll Modell Modell relaterad information Skicka ut meddelanden om förändringar Kontroll Tolka inmatning från användaren Fördela kontroll &5&NRUWÃI UÃÅ.ODVVLVNDÅÃ09& Vy Modell ([HPSHO Vi skall bygga ett datorsystem för ett universitetsbibliotek Några krav % FNHUÃRFKÃWLGQLQJDU. Biblioteket innehåller böcker och tidningar. Det kan finnas flera kopior av en given bok. Vissa böcker kan bara lånas på korttidslån. Alla andra böcker kan lånas av en lånekortsinnehavare i tre veckor. En lånekortsinnehavare kan normalt låna sex saker samtidigt, men anställda kan låna upp till 12 saker på en gång. Endast anställda får låna tidningar. /nq. Systemet måste hålla reda på när böcker och tidningar är lånade och tillbakalämnade under reglerna som beskrevs ovan. previous next 38 previous next 41, F7, F7 +XUÃKLWWDVÃNODVVHUÃRFKÃREMHNW" Vi har bla diskuterat användningsfall och scenarier som sätt att identifiera vad ett system skall göra Från dessa beskrivningar kan man hitta en del objekt i systemet (se Larman för detaljer och exempel) 2EMHNWGHVLJQLSUDNWLNHQ Från OOAD till XP Intresset för mer lättviktiga metoder som extreme Programming är stort Fast kanske inte riktigt än bland stora organisationer som fortfarande misslyckas med stil! (genom att använd RUP eller liknande...) Vi har också diskuterat CRC-kort som ett sätt att spåna fram klasser, ansvar och relationer CRC-kort Vi försöker brainstorma fram systemet Kan, självklart, kompletteras med en del UML-diagram ock liknande Senare i kursen kommer vi också diskutera designmönster som ett sätt att applicara återanvända och identifiera framgångsrika strukturer på olika designproblem Skriv tester först, designa lite, implementera det enklaste som fungerar, omstrukturera (eng. refactoring) Denna strategi har visat sig fungera bra H;WUHPHÃ3URJUDPPLQJÃ;3ÃUHIDFWRULQJÃWHVWQLQJÃPPÃ NRPPHUÃYLÃSUDWDÃPHUÃRPÃVHQDUHÃLÃNXUVHQ previous next 39 previous next 42 %M UQ(LGHUElFN 7