Design av objekt September 25, 2001 Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Email: [email protected] Innehåll Arv eller komposition/aggregering Cohesion och coupling Några mönster.
Download ReportTranscript Design av objekt September 25, 2001 Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Email: [email protected] Innehåll Arv eller komposition/aggregering Cohesion och coupling Några mönster.
Slide 1
Design av objekt
September 25, 2001
Hur skapar vi objekt och klasser?
Några grundläggande regler
Björn Eiderbäck
NADA, KTH
Email: [email protected]
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?
previous
next
Slide 2
OOMPA, F7
Objektkonstruktion
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)
previous
next
2
Slide 3
OOMPA, F7
Objektkonstruktion
Arv
• Vilka sorter finns?
• Varför ärver vi?
previous
next
3
Slide 4
OOMPA, F7
Objektkonstruktion
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
previous
next
4
Slide 5
OOMPA, F7
Objektkonstruktion
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
Shape
p osition : P oin t
A
B
C
b ou n d s() :R ectan gle
d raw () : void
ex ten t() : P oin t
D
S h a p e1
E
previous
next
S h a p e2
ex ten t : P oin t
ex ten t : P oin t
d raw () : void
d raw () : void
5
Slide 6
OOMPA, F7
Objektkonstruktion
..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
previous
next
6
Slide 7
OOMPA, F7
Objektkonstruktion
Javas basklass Object
• Klassen Object är överst i Javas klassträd
Object
equals(obj : Object) : boolean
toString() : String
getClass() : String
Boolean Number
Integer
Byte
String
Graphics
Button
Klassen Object
med några subklasser
och några viktiga metoder
Component
Label
Window
previous
next
Container
Panel
7
Slide 8
OOMPA, F7
Objektkonstruktion
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
previous
next
8
Slide 9
OOMPA, F7
Objektkonstruktion
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
previous
next
9
Slide 10
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
10
Slide 11
OOMPA, F7
Objektkonstruktion
Exempel: olika typer av arv
Arv för specialisering
Ellipse
Circle
Window
Win95Window
Arv för specifikation
MacWindow
MotorLandVehicle
tank
engine
wheels()
speed()
Car
previous
next
Bike
Lorry
MotorCycle
11
Slide 12
OOMPA, F7
Objektkonstruktion
...
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
GraphicComponent
previous
next
Car
Boat
AmfibieCar
12
Slide 13
OOMPA, F7
Objektkonstruktion
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
previous
next
13
Slide 14
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
14
Slide 15
OOMPA, F7
Objektkonstruktion
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
previous
next
15
Slide 16
OOMPA, F7
Objektkonstruktion
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
previous
next
16
Slide 17
OOMPA, F7
Objektkonstruktion
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
previous
next
17
Slide 18
OOMPA, F7
Objektkonstruktion
... komposition ...
Stack
data
Vector
isEmpty() : boolean
push(v : Object) : void
peek(): Object
pop() : Object
Stack() : Stack
previous
next
18
Slide 19
OOMPA, F7
Objektkonstruktion
...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;
}
}
previous
next
19
Slide 20
OOMPA, F7
Objektkonstruktion
... arv ...
Vector
Stack
push(v : Object) : void
peek(): Object
pop() : Object
previous
next
20
Slide 21
OOMPA, F7
Objektkonstruktion
... 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;
}
}
previous
next
21
Slide 22
OOMPA, F7
Objektkonstruktion
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
previous
next
22
Slide 23
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
23
Slide 24
OOMPA, F7
Objektkonstruktion
...
• 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
24
Slide 25
OOMPA, F7
Objektkonstruktion
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....
previous
next
25
Slide 26
OOMPA, F7
Objektkonstruktion
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
previous
next
26
Slide 27
OOMPA, F7
Objektkonstruktion
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)
previous
next
27
Slide 28
OOMPA, F7
Objektkonstruktion
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
previous
next
28
Slide 29
OOMPA, F7
Objektkonstruktion
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)
previous
next
29
Slide 30
OOMPA, F7
Objektkonstruktion
GRASP
• I Larman diskuteras objektdesign i form av en
uppsättning mönster
• General Responsibility Assignment Software Patterns
(GRASP)
previous
next
30
Slide 31
OOMPA, F7
Objektkonstruktion
Några mönster (från GRASP)
• Expert
• Creator
• Low Coupling
• High Cohesion
previous
next
31
Slide 32
OOMPA, F7
Objektkonstruktion
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
previous
next
32
Slide 33
OOMPA, F7
Objektkonstruktion
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
previous
next
33
Slide 34
OOMPA, F7
Objektkonstruktion
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
previous
next
34
Slide 35
OOMPA, F7
Objektkonstruktion
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
previous
next
35
Slide 36
OOMPA, F7
Objektkonstruktion
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
previous
next
36
Slide 37
OOMPA, F7
Objektkonstruktion
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
previous
next
37
Slide 38
OOMPA, F7
Objektkonstruktion
CRC-kort för "Klassiska" MVC
Vy
Visualisera
modellen
Transformera
koordinater
Kontroll
Modell
Kontroll
Tolka inmatning
Vy
från användaren Modell
Fördela kontroll
Modell
Problemrelaterad information
Skicka ut meddelanden om
förändringar
previous
next
38
Slide 39
OOMPA, F7
Objektkonstruktion
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
previous
next
39
Slide 40
OOMPA, F7
Objektkonstruktion
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
previous
next
40
Slide 41
OOMPA, F7
Objektkonstruktion
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.
previous
next
41
Slide 42
OOMPA, F7
Objektkonstruktion
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
previous
next
42
Design av objekt
September 25, 2001
Hur skapar vi objekt och klasser?
Några grundläggande regler
Björn Eiderbäck
NADA, KTH
Email: [email protected]
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?
previous
next
Slide 2
OOMPA, F7
Objektkonstruktion
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)
previous
next
2
Slide 3
OOMPA, F7
Objektkonstruktion
Arv
• Vilka sorter finns?
• Varför ärver vi?
previous
next
3
Slide 4
OOMPA, F7
Objektkonstruktion
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
previous
next
4
Slide 5
OOMPA, F7
Objektkonstruktion
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
Shape
p osition : P oin t
A
B
C
b ou n d s() :R ectan gle
d raw () : void
ex ten t() : P oin t
D
S h a p e1
E
previous
next
S h a p e2
ex ten t : P oin t
ex ten t : P oin t
d raw () : void
d raw () : void
5
Slide 6
OOMPA, F7
Objektkonstruktion
..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
previous
next
6
Slide 7
OOMPA, F7
Objektkonstruktion
Javas basklass Object
• Klassen Object är överst i Javas klassträd
Object
equals(obj : Object) : boolean
toString() : String
getClass() : String
Boolean Number
Integer
Byte
String
Graphics
Button
Klassen Object
med några subklasser
och några viktiga metoder
Component
Label
Window
previous
next
Container
Panel
7
Slide 8
OOMPA, F7
Objektkonstruktion
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
previous
next
8
Slide 9
OOMPA, F7
Objektkonstruktion
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
previous
next
9
Slide 10
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
10
Slide 11
OOMPA, F7
Objektkonstruktion
Exempel: olika typer av arv
Arv för specialisering
Ellipse
Circle
Window
Win95Window
Arv för specifikation
MacWindow
MotorLandVehicle
tank
engine
wheels()
speed()
Car
previous
next
Bike
Lorry
MotorCycle
11
Slide 12
OOMPA, F7
Objektkonstruktion
...
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
GraphicComponent
previous
next
Car
Boat
AmfibieCar
12
Slide 13
OOMPA, F7
Objektkonstruktion
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
previous
next
13
Slide 14
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
14
Slide 15
OOMPA, F7
Objektkonstruktion
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
previous
next
15
Slide 16
OOMPA, F7
Objektkonstruktion
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
previous
next
16
Slide 17
OOMPA, F7
Objektkonstruktion
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
previous
next
17
Slide 18
OOMPA, F7
Objektkonstruktion
... komposition ...
Stack
data
Vector
isEmpty() : boolean
push(v : Object) : void
peek(): Object
pop() : Object
Stack() : Stack
previous
next
18
Slide 19
OOMPA, F7
Objektkonstruktion
...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;
}
}
previous
next
19
Slide 20
OOMPA, F7
Objektkonstruktion
... arv ...
Vector
Stack
push(v : Object) : void
peek(): Object
pop() : Object
previous
next
20
Slide 21
OOMPA, F7
Objektkonstruktion
... 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;
}
}
previous
next
21
Slide 22
OOMPA, F7
Objektkonstruktion
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
previous
next
22
Slide 23
OOMPA, F7
Objektkonstruktion
...
• 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
previous
next
23
Slide 24
OOMPA, F7
Objektkonstruktion
...
• 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
24
Slide 25
OOMPA, F7
Objektkonstruktion
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....
previous
next
25
Slide 26
OOMPA, F7
Objektkonstruktion
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
previous
next
26
Slide 27
OOMPA, F7
Objektkonstruktion
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)
previous
next
27
Slide 28
OOMPA, F7
Objektkonstruktion
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
previous
next
28
Slide 29
OOMPA, F7
Objektkonstruktion
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)
previous
next
29
Slide 30
OOMPA, F7
Objektkonstruktion
GRASP
• I Larman diskuteras objektdesign i form av en
uppsättning mönster
• General Responsibility Assignment Software Patterns
(GRASP)
previous
next
30
Slide 31
OOMPA, F7
Objektkonstruktion
Några mönster (från GRASP)
• Expert
• Creator
• Low Coupling
• High Cohesion
previous
next
31
Slide 32
OOMPA, F7
Objektkonstruktion
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
previous
next
32
Slide 33
OOMPA, F7
Objektkonstruktion
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
previous
next
33
Slide 34
OOMPA, F7
Objektkonstruktion
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
previous
next
34
Slide 35
OOMPA, F7
Objektkonstruktion
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
previous
next
35
Slide 36
OOMPA, F7
Objektkonstruktion
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
previous
next
36
Slide 37
OOMPA, F7
Objektkonstruktion
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
previous
next
37
Slide 38
OOMPA, F7
Objektkonstruktion
CRC-kort för "Klassiska" MVC
Vy
Visualisera
modellen
Transformera
koordinater
Kontroll
Modell
Kontroll
Tolka inmatning
Vy
från användaren Modell
Fördela kontroll
Modell
Problemrelaterad information
Skicka ut meddelanden om
förändringar
previous
next
38
Slide 39
OOMPA, F7
Objektkonstruktion
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
previous
next
39
Slide 40
OOMPA, F7
Objektkonstruktion
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
previous
next
40
Slide 41
OOMPA, F7
Objektkonstruktion
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.
previous
next
41
Slide 42
OOMPA, F7
Objektkonstruktion
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
previous
next
42