Hur skapar vi objekt och klasser? Några grundläggande regler Design av objekt September 25, 2001 Hur skapar vi objekt och klasser? Några grundläggande regler Björn Eiderbäck NADA, KTH Email: bjorne@nada.kth.se 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?

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)

Arv Vilka sorter finns? Varför ärver vi?

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

Arv Arv är fundamentalt i objektorienterad programmering A B C D E 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 B C D E

..arv Arv kan delas in i två huvudtyper Arv kan vara av olika typ 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

och några viktiga metoder Javas basklass Object Klassen Object är överst i Javas klassträd Object equals(obj : Object) : boolean toString() : String getClass() : String Klassen Object med några subklasser och några viktiga metoder Boolean Number String Graphics Component Button Label Container Byte Integer Window Panel

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

Olika former av arv Arv för specialisering Arv för specifikation 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

... Arv för utvidgning Arv för begränsning Arv för kombination 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

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

... 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

Fördelar med arv Återanvändning av mjukvara Ökad tillförlitlighet 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

... Mjukvarukomponenter Snabb konstruktion av prototyper 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

Kostnader för arv Exekveringshastighet Programstorlek 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

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

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 Komposition Arv

... komposition ...

...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; }

... arv ...

... 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; }

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

... 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

... 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

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....

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

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)

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

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)

GRASP I Larman diskuteras objektdesign i form av en uppsättning mönster General Responsibility Assignment Software Patterns (GRASP)

Några mönster (från GRASP) Expert Creator Low Coupling High Cohesion

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

Creator Problem Lösning Exempel 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

Low Coupling Problem Lösning Exempel 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

High Cohesion Problem Lösning Exempel 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

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

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

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

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

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

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.

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