Presentation laddar. Vänta.

Presentation laddar. Vänta.

Next previous Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Innehåll.

Liknande presentationer


En presentation över ämnet: "Next previous Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Innehåll."— Presentationens avskrift:

1 next previous Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH 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? Design av objekt September 25, 2001

2 previous next 2 Objektkonstruktion OOMPA, F7 Arv eller aggregering? •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 •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)

3 previous next 3 Objektkonstruktion OOMPA, F7 Arv •Vilka sorter finns? •Varför ärver vi?

4 previous next 4 Objektkonstruktion OOMPA, F7 Aggregering eller komposition •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

5 previous next 5 Objektkonstruktion OOMPA, F7 Arv •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 subklasser ärva både struktur och attribut från superklasser •dvs både variabler och metoder ärvs A BC E D

6 previous next 6 Objektkonstruktion OOMPA, F7..arv •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

7 previous next 7 Objektkonstruktion OOMPA, F7 Javas basklass Object •Klassen Object är överst i Javas klassträd Boolean Number Byte String Integer GraphicsComponent ButtonLabel Container Window Panel Object equals(obj : Object) : boolean toString() : String getClass() : String Klassen Object med några subklasser och några viktiga metoder

8 previous next 8 Objektkonstruktion OOMPA, F7 Subklass, subtyp och ersättbarhet •Abstrakt datatyp –Är en inkapsling av data och dom metoder som opererar på dessa data •Subtyp –En viss typ A är subtyp 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

9 previous next 9 Objektkonstruktion OOMPA, F7 Olika former av arv •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

10 previous next 10 Objektkonstruktion OOMPA, 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

11 previous next 11 Objektkonstruktion OOMPA, F7 Exempel: olika typer av arv Ellipse Circle Window Win95Window MacWindow Arv för specialisering Arv för specifikation Car Bike Lorry MotorCycle MotorLandVehicle tank engine wheels() speed()

12 previous next 12 Objektkonstruktion OOMPA, F7... Arv för konstruktionArv för utvidgningArv för begränsning Arv för kombination Polyline Cartoon Vector Stack Ellipse Circle Vector Set Collection GraphicComponent GraphicObject Car AmfibieCar Boat

13 previous next 13 Objektkonstruktion OOMPA, F7 Fördelar med arv •Å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

14 previous next 14 Objektkonstruktion OOMPA, F7... •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

15 previous next 15 Objektkonstruktion OOMPA, F7 Kostnader för arv •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

16 previous next 16 Objektkonstruktion OOMPA, F7 Mekanismer för återanvändning av mjukvara •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

17 previous next 17 Objektkonstruktion OOMPA, F7 Komposition eller arv •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 1.Komposition 2.Arv

18 previous next 18 Objektkonstruktion OOMPA, F7... komposition...

19 previous next 19 Objektkonstruktion OOMPA, F7...komposition... class Stack{ protected Vector data; public Stack() {data = new Vector();} public boolean isEmpty() {return data.isEmpty();} public void push(Object v) {data.addElement(v);} public Object peek() {return data.lastElement();} public Object pop(){ Object result = peek(); data.removeElementAt(data.size() - 1); return result; }

20 previous next 20 Objektkonstruktion OOMPA, F7... arv...

21 previous next 21 Objektkonstruktion OOMPA, F7... arv class Stack extends Vector{ public void push(Object v) {addElement(v);} public Object peek() {return lastElement();} public Object pop(){ Object result = peek(); removeElementAt(size() - 1); return result; }

22 previous next 22 Objektkonstruktion OOMPA, F7 Arv eller komposition? •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

23 previous next 23 Objektkonstruktion OOMPA, F7... •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 •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 •Arv låter oss använda den nya abstraktionen som argument i en polymorf funktion

24 previous next 24 Objektkonstruktion OOMPA, F7... •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

25 previous next 25 Objektkonstruktion OOMPA, F7 Cohesion •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 •Kaffekokarn brygger kaffe men skickar inte fax....

26 previous next 26 Objektkonstruktion OOMPA, F7 Coupling •Med coupling menas hur mycket olika komponenter beror av, eller är relaterade till, varandra •Man strävar efter att bygga system med så lite coupling mellan komponenterna som möjligt •En strävan är att om ett objekt ändras så ska så få andra objekt som möjligt påverkas

27 previous next 27 Objektkonstruktion OOMPA, F7 Generella kodningsregler (ett urval...) •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)

28 previous next 28 Objektkonstruktion OOMPA, F7 Något om designmönster •Ett designmönster beskriver lösningar på ett sätt så att mönstret kan användas i olika (snarlika) situationer "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same twice " Christopher Alexander 1977 "A design pattern simply captures the salient characteristics of a solution to a problem that has been observed to occur repeatedly in many different problem domains" Budd 1997 "A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context" Gamma & co 1995

29 previous next 29 Objektkonstruktion OOMPA, F7 Varför designmönster? 1.Dom erbjuder expertkunskap 2.Dom ger oss en kraftfull vokabulär 3.Vi förstår programsystem snabbare om dom är dokumenterade med designmönster 4.Dom förenklar omstrukturering av system (underhåll)

30 previous next 30 Objektkonstruktion OOMPA, F7 GRASP •I Larman diskuteras objektdesign i form av en uppsättning mönster •General Responsibility Assignment Software Patterns (GRASP)

31 previous next 31 Objektkonstruktion OOMPA, F7 Några mönster (från GRASP) •Expert •Creator •Low Coupling •High Cohesion

32 previous next 32 Objektkonstruktion OOMPA, F7 Expert Problem –Hur tilldelar man ansvar till objekt? Lösning –Tilldela ansvaret till ”informationsexperten”, dvs den klass som har nödvändig informationen för att lösa problemet Exempel –Se Larman 16.6

33 previous next 33 Objektkonstruktion OOMPA, F7 Creator Problem –Vem ansvarar för att skapa nya instanser av en viss klass? Lösning –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) Exempel –Se Larman 16.7

34 previous next 34 Objektkonstruktion OOMPA, F7 Low Coupling Problem –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? Lösning –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 Exempel –Se Larman 16.8

35 previous next 35 Objektkonstruktion OOMPA, F7 High Cohesion Problem –Hur gör man systemets komplexitet så hanterbar som möjligt? Lösning –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. Exempel –Se Larman 16.9

36 previous next 36 Objektkonstruktion OOMPA, F7 Modulär Design •Redan innan objektorienterad programmering försökte man dela in ett system på olika moduler eller paket som gjorde (väldefinierat) olika saker

37 previous next 37 Objektkonstruktion OOMPA, F7 Mönstret Controller •Från ”70-talsmönstret” Model View Controller (MVC) •Grundidén är att separera logik, kontroll och presentation från varandra •Vi vill alltså att ett visst objekt ansvarar för kontrollen, dvs tar hand om händelser, tex från mus och tangentbord •MVC är också pappa till massa andra mönster –Två av dom mest kända är •Observer •Factory method CRC-kort

38 previous next 38 Objektkonstruktion OOMPA, F7 CRC-kort för "Klassiska" MVC Vy Visualisera modellen Transformera koordinater Kontroll Modell Problemrelaterad information Skicka ut meddelanden om förändringar Kontroll Tolka inmatning från användaren Fördela kontroll Vy Modell

39 previous next 39 Objektkonstruktion OOMPA, F7 Hur hittas klasser och objekt? •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) •Vi har också diskuterat CRC-kort som ett sätt att spåna fram klasser, ansvar och relationer •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

40 previous next 40 Objektkonstruktion OOMPA, F7 Ett annat sätt är: Wirfs-Brocks nominalfras-strategi •Läs och förstå kravdokumentet. Målet är att hitta en modell som väl avspeglar den aktuella problemdomänen •Läs igenom dokumentet igen. Titta speciellt efter nominalfraser. Skapa en preliminär lista av dessa fraser och ändra alla plural till singular •Dela nominalfraserna i tre kategorier: definitivt objekt, nonsensobjekt och möjliga objekt •Strunta i nonsenobjekten •Diskutera "möjliga objekt" och placera vart ett av dom i någon av dom andra två kategorierna

41 previous next 41 Objektkonstruktion OOMPA, F7 Exempel •Vi skall bygga ett datorsystem för ett universitetsbibliotek •Några krav –Böcker och tidningar. 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. –Lån. Systemet måste hålla reda på när böcker och tidningar är lånade och tillbakalämnade under reglerna som beskrevs ovan.

42 previous next 42 Objektkonstruktion OOMPA, F7 Objektdesign i praktiken •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...) •CRC-kort –Vi försöker ”brainstorma” fram systemet –Kan, självklart, kompletteras med en del UML-diagram ock liknande •Skriv tester först, designa lite, implementera det enklaste som fungerar, omstrukturera (eng. refactoring) –Denna strategi har visat sig fungera bra •eXtreme Programming (XP), refactoring, testning, mm kommer vi prata mer om senare i kursen


Ladda ner ppt "Next previous Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Innehåll."

Liknande presentationer


Google-annonser