OOP - OBJEKTORIENTERAD PROGRAMMERING

Transkript

1 OOP - OBJEKTORIENTERAD PROGRAMMERING Det som skiljer objektorienterad programmering, OOP, från den traditionella, imperativa programmeringsstilen, är världssynen. Inom den imperativa traditionen - och hittills har vi programmerat även Java enligt denna syn - är det processer som är det viktiga. När vi lär oss att programmera, ska vi först designa en algoritm, som berättar hur uppgiften skall lösas, vilka instruktioner datorn skall utföra och i vilken ordning, för att få fram det önskade resultatet. Inom imperativ programmering är det alltså processen som är det centrala, data något sekundärt, det som påverkas av processen. Ex. anta att vi ska designa ett nytt datasystem för ett bibliotek. Det första vi frågar oss är vilka processer som äger rum i biblioteket, dvs. vilka processer som ska ingå i det nya systemet. Vi kommer kanske fram till följande lista: $ att låna ett exemplar av en bok $ att returnera ett exemplar $ att reservera en bok (obs! inte ett exemplar - varför?) $ att skicka kravbrev på ett exemplar $ att registrera en ny kund $ att söka information om en bok Alla dessa punkter är processer - att låna, att returnera, att reservera. Inom denna världsbild består den aktiva världen, det som vårt nya datasystem skall reflektera, av processer. De som påverkas av processerna, kunderna, exemplaren, kravbreven, böckerna, ses som objekt, data som påverkas av processerna. Processerna är det primära, data något sekundärt. Java II med Annamari, närpass 3: Objektorienterad design 1

2 Inom OOP är synen på världen radikalt annorlunda. Grundtanken inom OOP är att vi, normala människor som inte ännu har blivit hjärntvättade av datalogistudier, strukturerar världen helt annorlunda. När vi kommer in in ett bibliotek så är det ingalunda processerna som vi först fäster uppmärksamhet vid, utan de fysiska objekten: böckerna (eller egentligen exemplaren), människorna (kunderna och personalen), hyllorna. Det är de som intresserar oss: vi vill kanske söka information om en viss bok, och antingen reservera boken eller låna ut ett exemplar av den, ifall vi hittar ett på rätta hyllan. För att hitta den rätta hyllan ber vi kanske bibliotekarien om hjälp. Observera, att både vi själva och bibliotekarien vi ber om hjälp räknas här bland de fysiska objekten - inget illa menat med det! När vi då analyserar världen enligt denna programmeringsparadigm, så är det objekten som blir det centrala. Processerna blir något sekundärt, de blir egenskaper, attribut, hos objekten. Ex. objektet bibliotekskund kan ha följande attribut (egenskaper): - kundnummer - namn - adress (så vi vet vart skicka kravbreven) - en lista över innestående lån * att reservera en bok * att låna ett exemplar * att returnera ett exemplar * lista innestående lån * betala böten * utföra en sökning Jag har markerat med '-' de egenskaper som beskriver objektet i fråga, och med '*' de egenskaper som är processer som objektet kan utföra. I Java skulle vi tala om variabler respektive metoder. Båda dessa kan räknas som attribut; de beskriver objektet i fråga. Terminologin inom OOP är inte enhetlig. Jag ska i fortsättningen kalla dessa för attribut respektive processer i allmänhet, variabler respektive metoder i Java i synnerhet. Java II med Annamari, närpass 3: Objektorienterad design 2

3 Objektet bok skulle kunna ha följande attribut och processer: - ISBN-numret - namnet - författarens namn - förlaget - tryckort - tryckår - antalet exemplar - reservationslista (en FIFO-kö) * skriva ut första människan på reservationslistan * sätta till en ny reservation i slutet av kön Ett exemplar av en bok skulle ärva vissa av egenskaperna hos en bok: - ISBN-numret - namnet - författarens namn - förlaget - tryckort - tryckår Därutöver skulle varje exemplar tillhörande en bok ha vissa egna attribut: - exemplarnummer * kan utlånas - till vem? * kan förstöras/försvinna * kan returneras Vi skall diskutera begreppet arv (nedärvning) senare; exemplet ovan ska exemplifiera OOP helt allmänt. Att börja koda ett dylikt bibliotekssystem skulle kräva rätt så avancerade kunskaper i Java och databashantering, så vi ska koda enklare exempel först. Efter att du har tagit kursen i Databaser torde du kunna koda exemplet ovan utan större problem. Java II med Annamari, närpass 3: Objektorienterad design 3

4 EGENSKAPER HOS OOP - ALLMÄN PRESENTATION De egenskaper som vi skall diskutera nedan gäller allmänt för objektorienterad design. Vissa av dessa principer kan vi försöka tillämpa även när vi jobbar med traditionella, imperativa programmeringsspråk som Pascal, Modula-2 eller C. De språk som gör anspråk på att vara speciellt objektorienterade, ex. Beta, Eiffel, C++ eller Java, har implementerat (konkretiserat, förverkligat) dessa egenskaper på olika sätt. Här är det alltså frågan om allmänna principer som du kan vänta dig att hitta implementerade på olika sätt i olika objektorienterade språk. Vi skall först titta på dessa principer, sedan ska vi se exempel på hur Java har implementerat dem. OOP Java C++ Beta Eiffel... Den objektorienterade världssynen som vi beskrev ovan är gemensamt för alla dessa språk: det centrala är objekten, processerna är egenskaper hos enskilda objekt, något som dessa kan utföra. Härtill kommer det tre centrala principer: DATAINKAPSLING (data incapsulation) ARV(NEDÄRVNING) (inheritance) FLERFORMIGHET (polymorphism) Dessa tre skall förklaras nedan, först allmänt, sedan med Java-exempel. (Egentligen exemplifierar figuren ovan redan dessa principer: de olika programmeringsmetoderna är inkapslade i dessa olika språk; alla ärver de vissa principer från OOP, men de implementerar dessa på olika sätt.) Java II med Annamari, närpass 3: Objektorienterad design 4

5 DATAINKAPSLING: Datainkapsling innebär att man "kapslar in" data och metoder som hör ihop (tänk på hur de olika ingredienserna är inkapslade i medicinkapsyler!). Idén är att sammanhörande data skall kunna hanteras som en enhet, och att utomstående programdelar inte kommer åt dessa delar separat om vi inte uttryckligen önskar det. Många OOP-språk - inklusive Java - har ytterst sofistikerade hierarkier på dylika "kapslar", och ytterst mångskiftande regler på hur och varifrån deras olika delar kan accesseras - eller inte accesseras. I Java har vi ex. paket, klasser, objekt, instanser, metoder osv. som alla fungerar som helheter bestående av separata delar. Ofta är det helheten vi vill arbeta med, i vissa situationer delarna. I våra Java-exempel brukar vi ex. importera paketet javagently för att komma åt den extremt nyttiga Text-klassen, som i sin tur består av flera användbara metoder för att läsa in och skriva ut olika sorters värden, eller hjälpa oss med filhantering. Vi behöver bara känna till namnet på metoden och hur vi skall anropa den, och så utförs metoden för oss. Det som vi däremot inte behöver känna till är hur metoden är implementerad, vilka kommandon den utför. Det ena enda som intresserar oss är resultatet. Det är detta som förstås med inkapsling. javagently Text * Text.readInt * Text.readDouble * Text.readChar * Text.readString * Text.writeDouble *... Om vi tänker på biblioteksexemplet ovan, så skulle både kunden, boken och exemplaret vara inkapslade som objekt: inne i detta objekt finns alla de olika attributerna, både de "vanliga" och processerna, som tillhör just detta objekt. I Java skulle vi kalla ett dylikt objekt för en klass (ex. kund) och de olika verkliga kunderna för instanser av denna klass. Java II med Annamari, närpass 3: Objektorienterad design 5

6 ARV/NEDÄRVNING (INHERITANCE) Typiskt för OOP är att de olika objekten (eller klasserna, om vi vill använda Javas terminologi) utgör en hierarki. Ex. Människa Personalmedlem Studerande Lektor Professor DI IB Vi ser av figuren ovan att vi har två sorters människor i vårt system - personalmedlemmar och studerande. Personalmedlemmarna delar sig vidare i lektorer och professorer, och de studerande i DI (blivande diplomingengörer) och IB (blivande filosofie magistrar). I denna ytterst förenklade värld kan vi dock studera begreppet arv riktigt bra: de egenskaper som är gemensamma för alla människor definieras hos objektet människa. Både personalmedlemmar och studerande är människor (även om det inte alltid känns så...) och de ärver alla de egenskaper som är gemensamma för alla människorna, dvs. alla de egenskaper, attribut och processer, som är deklarerade för objektet människa. Men: det finns egenskaper hos personalmedlemmar, ex. titel, undervisningsskyldighet och löneklass, som ingalunda gäller för alla människor. Dessa deklareras separat för klassen Personalmedlem. På motsvarande sätt, det finns egenskaper som är specifika för de studerande, som ex. matrikelnummer och en lista över avklarade kurser. Dessa deklareras separat för klassen Studerande. Vidare indelas klassen Personalmedlem i lektorer och professorer. Dessa ärver alla de egenskaper som gäller för personalmedlemmar (och därvia människor), men kan deklarera sina egna Java II med Annamari, närpass 3: Objektorienterad design 6

7 attribut; för professorsklassen kommer det ex. massor av administrativa skyldigheter och ledning av forskningsprojekt, medan lektorerna kanske utför olika sorters institutionsarbeten. När det gäller de studerande så är kraven på DI-studerande och IB-linjen olika, och dessa skall deklareras separat för dessa objekt: Ex. Människa - namn - personnummer - adress Personalmedlem Studerande - institution - matrikelnummer - löneklass - STURE-rapport - undervisningsskyldighet Lektor Professor DI IB - institutionsarbeten - forskningsprojekt - krav - krav på på 180 sv 160 sv Om vi nu skapar en instans av objektet (klassen) DI, så ska denna blivande DI ha följande egenskaper: - namn (ärvs från Människa) - personnummer (ärvs från Människa) - adress (ärvs från Människa) - matrikelnummer (ärvs från Studerande) - STURE-rapport (ärvs från Studerande) - krav på 180 sv (ärvs från DI) Java II med Annamari, närpass 3: Objektorienterad design 7

8 I början är dessa attribut tomma. Efter att vi har skapat instansen i fråga kan vi börja fylla i namn etc: - namn (ärvs från Människa) Axel - personnummer (ärvs från Människa) J - adress (ärvs från Människa) Tavasthem 13 - matrikelnummer (ärvs från Studerande) STURE-rapport (ärvs från Studerande) en lång lista - krav på 180 sv (ärvs från DI) en ännu längre lista För att Axel inte behöver studera ensam kan vi skapa en ny instans av samma klass, Stina: - namn (ärvs från Människa) Stina - personnummer (ärvs från Människa) Y - adress (ärvs från Människa) Tavasthem 15 - matrikelnummer (ärvs från Studerande) STURE-rapport (ärvs från Studerande) en lång lista - krav på 180 sv (ärvs från DI) en ännu längre lista I allmänt språkbruk skulle vi kunna kalla både Axel och Stina för objekt, eller instanser av objekt. Vill vi lära oss Javas språkbruk kommer vi att kalla både Axel och Stina för instanser av klassen DI. Klassen DI utvidgar klassen Studerande, som i sin tur utvidgar klassen Människa. Klassen DI är en subklass av klassen Studerande som är en subklass av klassen Människa. Klassen Människa är en superklass av klassen Studerande som är en superklass av klassen DI. Du kan också använda termerna delklass och överklass i stället för subklass rspektive superklass. Så användbar som det ofta skulle vara att låta ett objekt ärva egenskaper från två eller flera olika klasser så tillåter Java inte detta! Ex. vi kan inte definiera en klass Lärarstudent som skulle ärva från både Personalmedlem och Studerande. Java II med Annamari, närpass 3: Objektorienterad design 8

9 FLERFORMIGHET (POLYMORPHISM) (Franzén talar om ungefär samma sak under termerna skuggning och överskuggning.) När det gäller olika subklasser till en bestämd superklass, så är det ofta så att alla dessa subklasser har en viss gemensam metod, som ändå tar sig lite olika former beroende på vilken delklass det är frågan om. Ex. både klassen Lektor och klassen Professor kunde ha en metod årsrapport. Denna metod skulle planera årsrapporten för den ifrågavarande personalmedlemmen. Eftersom det dyker upp lite olika sysslor för lektorer och professorer så är det bäst att de båda delklasserna definierar var för sig vad som ska komma med i årsrapporten. För en lektor skulle årsrapport ta med exempelvis följande punkter: - Vilka kurser lektorn har undervisat - Hur många studieveckor per år lektorn har producerat - Vilka förtroendeuppgifter lektorn har haft - Vilka kurser lektorn själv har gått på - Undervisningsmaterial lektorn har producerat I professorns motsvarande rapport skulle det kunna så ex. följande: - Vilka forskarkurser professorn har undervisat - Hur många doktorsavhandlingar hon har handlett - Hur många licensiatavhandlingar hon har handlett - Hur många magisters/di-avhandlingar hon har handlett - Hur mycket extern finansiering hon har skaffat - Hur många artiklar hon har publicerat - Hur många konferenser hon har hållit föredrag på Uppgiften av metoden skrivarapport skulle vara densamma: att skriva ut denna årsrapport när den behövs. Därför väljer vi att kalla denna metod för skrivarapport, både för klassen Lektor och för klassen Professor. Strukturen hos dessa rapporter varierar dock beroende på tjänsteklassen. Det är detta som vi kallar för flerformighet. Java II med Annamari, närpass 3: Objektorienterad design 9

10 Man kan också tänka sig att det fanns en metod med namnet skrivarapport definierad för klassen Personalmedlem. Eftersom det säkert finns många olika delklasser till denna överklass utöver våra lektorer och professorer, så kommer det att finnas bara mycket allmänna saker att skriva ut i denna metod. Vi säger då att metoden skrivarapport väljer sin form beroende av hurdant objekt det är som skriver ut sin rapport: om instansen som ska skriva ut sin rapport hör direkt till klassen Personalmedlem, så skrivs det ut bara dessa allmänna saker. Om instansen hör till klassen Lektor, skrivs det ut en lektorsrapport. Om instansen hör till klassen Professor, skrivs det ut en professorsrapport. I dessa två senare fall säger vi att instanserna i klasserna Lektor och Professor överskuggar metoden skrivarapport i klassen Personalmedlem: Ex. Människa - namn - personnummer - adress Personalmedlem Studerande - institution - matrikelnummer - löneklass - STURE-rapport - undervisningsskyldighet * skrivarapport (bara namn etc.) Lektor Professor DI IB - institutionsarbeten - forskningsprojekt - krav - krav * skrivarapport * skrivarapport Java II med Annamari, närpass 3: Objektorienterad design 10

11 Vi kan tänka oss två lektorer, Ragnar och Annamari, och två professorer, Kaj och Karin. Deras rapporter skulle kunna ha följande utseende: instans: Ragnar klass: Lektor - Vilka kurser lektorn har undervisat: -DYD,-DYD,,ODEE, - Hur många studieveckor per år lektorn har producerat: " - Vilka förtroendeuppgifter lektorn har haft: 2OLNDLQVWLWXWLRQVDUEHWHQIRUVNQLQJVSURMHNW - Vilka kurser lektorn själv har gått på: $YDQFHUDG$,VFKDFNI UH[SHUWHUJLVVDU - Undervisningsmaterial lektorn har producerat: 8WPDQDGH-DYDSURJUDPI UOLWHOlQJUHKXQQD 6XSHUXWPDQDQGH-DYDSURJUDPI UJHQLHU instans: Annamari - Vilka kurser lektorn har undervisat:,qwurwloo,%lqwurwloo,%.7)'67.7)-dyd (;)257SURVHPLRP3ODWRQGDWDHWLN - Hur många studieveckor per år lektorn har producerat " - Vilka förtroendeuppgifter lektorn har haft: VLWWHUSnLQVWLWXWLRQVUnGHW - Vilka kurser lektorn själv har gått på LPPDWHULDDOLRLNHXGHWYHUNRVVDKLVWRULHILORVRIL - Undervisningsmaterial lektorn har producerat: (QNOD-DYDSURJUDPI UQ\E UMDUH Java II med Annamari, närpass 3: Objektorienterad design 11

12 Våra två professorer, däremot, kunde ha följande rapporter: instans: Kaj klass: Professorer - Vilka forskarkurser professorn har undervisat $GYDQFHGYHULILFDWLRQDOJRULWKPV 0XOWLPHGLD - Hur många doktorsavhandlingar han har handlett - Hur många licensiatavhandlingar han har handlett - Hur många magisters/di-avhandlingar han har handlett - Hur mycket extern finansiering hon har skaffat É - Hur många artiklar han har publicerat - Hur många konferenser han har hållit föredrag på instans: Karin - Vilka forskarkurser professorn har undervisat (YHQPRUHDGYDQFHGYHULILFDWLRQDOJRULWKPV (PEHGGHGV\VWHPV - Hur många doktorsavhandlingar hon har handlett - Hur många licensiatavhandlingar hon har handlett - Hur många magisters/di-avhandlingar hon har handlett - Hur mycket extern finansiering hon har skaffat É - Hur många artiklar hon har publicerat - Hur många konferenser hon har hållit föredrag på Java II med Annamari, närpass 3: Objektorienterad design 12

13 Som vi ser av exemplen ovan, rapportens struktur, dess utformning, beror på vilken klass instansen som skriver ut sin rapport tillhör: Ragnar och Annamari skriver ut lektorsrapporter medan Kaj och Karin skriver ut professorsrapporter. Rapporternas innehåll varierar naturligtvis beroende på vilken instans det är som skriver ut sin rapport: även om Ragnar och Annamari får liknande tomma blanketter att fylla i, kommer de att skriva olika saker i sina rapporter, för de har hållit och gått på olika kurser. Det som ärvs är strukturen, inte innehållet. Varje instans av en klass ärver variablerna och metoderna av sin klass om vi inte anger annat. Det som varierar med flerformighet är strukturen (det anses vara självklart att innehållet varierar). Vi kan ha flera olika metoder med namnet skrivrapport, men de skriver ut olika saker beroende på vilken sorts instans som anropar dem. SLUT PÅ TEORIN, DAGS FÖR JAVA-EXEMPEL!!! Java II med Annamari, närpass 3: Objektorienterad design 13

14 Manniska.java import java.io.*; import javagently.*; class Manniska { // instansvariabler - varje instans av ett objekt har // dessa String namn; // konstruktor - dessa sker när vi skapar nya instanser // av denna klass Manniska() { namn = ""; antal++; // en ny människa till har skapats // instansmetoder - detta kan de enskilda instanserna // utföra void presentera() throws IOException { BufferedReader in = Text.open(System.in); System.out.println("Hej, jag heter " + namn + "! "); // klassvariabler - gäller bara för klassen som helhet static int antal; Java II med Annamari, närpass 3: Objektorienterad design 14

15 Varje instans av klassen Manniska som vi skapar kommer att få instansvariablerna och instansmetoderna från denna klass: Manniska + antal (bara klass) - namn * presentera - namn - namn - namn - namn * presentera * presentera * presentera * presentera För att någonting skulle HÄNDA i vårt programsystem måste vi ha en klass som har en main-metod. Det är denna som utgör programmet som körs. Här berättar vi bara hur klassen Manniska.java ser ut, och hur dess olika instanser skulle se ut. Vi ser också vad som händer när vi skapar en instans; det ser vi av klassens konstruktor: // konstruktor - dessa sker när vi skapar nya instanser // av denna klass Manniska() { namn = ""; antal++; // en ny människa till har skapats För varje nyn instans av klassen Manniska som vi skapar kommer instansvariabeln namn at initialiseras till tomsträng, och klassvariabeln antal i själva klassen att ökas med 1; på detta sätt kan vi lätt hålla reda på hur många människor vi har skapat. Varje instans har sina egna instansvariabler. Klassvariablerna förekommer bara på ett ställe - klassen själv - och i ett exemplar. Java II med Annamari, närpass 3: Objektorienterad design 15

16 Larare.java och Elev.java import java.io.*; import javagently.*; class Larare extends Manniska { // instansvariabler - varje instans av ett objekt har // dessa String titel; // konstruktor - dessa sker när vi skapar nya instanser // av denna klass Larare() { titel = ""; // instansmetoder - detta kan de enskilda instanserna // utföra void presentera() throws IOException { BufferedReader in = Text.open(System.in); System.out.println("Hej, jag heter " + titel + " " + namn + "! "); void mänskligtpresentera () throws IOException { super.presentera(); Java II med Annamari, närpass 3: Objektorienterad design 16

17 Vi ser att klassen Larare nu blir en delklass av klassen Manniska; den utvidgar klassen Manniska. Dvs. varje instans av klassen Larare ärver alla de attribut som en instans av klassen Manniska skulle ha (namn och presentera). Därutöver kommer varje lärare att ha egna attribut och metoder: - namn (ärvs från Manniska) - titel * presentera (överskuggar metoden presentera från Manniska) * mänskligtpresentera (tillhandahåller ändå metoden presentera, såsom den ser ut i klassen Manniska - i vissa situationer, ex. på semesterresor, vill också lärare vara vanliga människor... ) Konstruktorn visar att när en ny lärare skapas, sätts titeln till tomsträng. Enligt Franzén ärvs konstruktorer inte. Jag är inte säker på vad han menar med detta: när vi skapar nya instanser av klassen Larare så är dessa samtidigt nya människor, och de räknas alldeles korrekt in i klassvariabeln antal i klassen Manniska såsom vi strax skall se. Men, låt oss först ta en titt på klassen Elev: Java II med Annamari, närpass 3: Objektorienterad design 17

18 import java.io.*; import javagently.*; class Elev extends Manniska { // instansvariabler - varje instans av ett objekt har // dessa int matr, antalkurser; Kurs [] kurser; // konstruktorer - dessa sker när vi skapar nya instanser // av denna klass Elev () { kurser = null; antalkurser = 0; Elev(int mnr) { matr = mnr; kurser = null; antalkurser = 0; Elev(int mnr, String n) { matr = mnr; namn = n; // nedärvs från Manniska kurser = null; antalkurser = 0; // instansmetoder - detta kan de enskilda instanserna // utföra void presentera() throws IOException { BufferedReader in = Text.open(System.in); System.out.println("Hej, jag heter " + namn + ", matrikelnr " + matr + "! "); Java II med Annamari, närpass 3: Objektorienterad design 18

19 void mänskligtpresentera () throws IOException { super.presentera(); void deltar (Kurs önskadkurs) { önskadkurs.antal++; // ökas vid den önskade kursen if (kurser == null) kurser = new Kurs [50]; kurser[antalkurser] = önskadkurs; antalkurser++; // för eleven i fråga Vi ser att varje elev har följande egenskaper: - namn (ärvs från Människa) - matr - antalkurser - kurser (en lista över elevens kurser) * presentera (överskuggar metoden i Manniska) * mänskligtpresentera (tillhandahåller ändå metoden från Människa) * deltar (i olika kurser) Dessutom har vi hela tre olika konstruktorer för elever: Elev(), om vi inte vet någonting om eleven i fråga. Elev(mnr), om vi känner till matrikelnumret till eleven. Elev(mnr, n), om vi känner till både matrikelnumret och namnet. Nu kan vi äntligen se på ett program som skapar dylika instanser och aktiverar dem... (vi lämnar objektet (klassen) Kurs för lite senare). Java II med Annamari, närpass 3: Objektorienterad design 19

20 Manniskotest.java import java.io.*; import javagently.*; class Manniskotest { /* Klassen Manniskotest exemplifierar nedärvning och polymorfi; klasserna Larare och Elev utvidgar Manniska, och överskuggar dess metod presentera. */ public static void main (String [] args) throws IOException { Manniska RW = new Manniska(); Manniska AMS = new Manniska(); RW.namn = "Ragnar"; AMS.namn = "Annamari"; RW.presentera(); AMS.presentera(); /* System.out.println("Annamari har " + AMS.antal + " medl."); Kommer att skriva ut samma antal som hela klassen har; syftar alltså till klassvariabeln antal i den klass AMS tillhör */ Larare Ralph = new Larare(); Larare Paul = new Larare(); Ralph.namn = "Ralph Back"; Ralph.titel = "Professor"; Paul.namn = "Paul Lindholm"; Paul.titel = "Lektor"; System.out.println("\n"); Java II med Annamari, närpass 3: Objektorienterad design 20

21 Ralph.presentera(); Paul.presentera(); System.out.println("\n"); Elev Ann = new Elev(13012); Elev Bo = new Elev(14516); /* Konstruktorn in klass Elev kräver att matrikelnummern kommer med. Man kan ju också sätta dit en ny konstruktor utan matrikelnummer. */ Elev Carin = new Elev(); Ann.namn = "Ann Saarela"; Bo.namn = "Bo Persson"; Carin.namn = "Carin Sund"; Ann.presentera(); Bo.presentera(); Carin.presentera(); System.out.println("\n"); System.out.println("människoklassen har " + Manniska.antal + " medl."); /* testar superklassen - även om Ann tolkas som en Manniska, ändras inte hennes presentation!!! */ Manniska AnnHemma = (Manniska) Ann; AnnHemma.presentera();... producerar matrikelnummer och allt i utskriften. System.out.println("människoklassen har " + Manniska.antal + " medl.");... visar att antalet människor inte har ändrats; Ann och AnnHemma syftar till ett och samma objekt. Java II med Annamari, närpass 3: Objektorienterad design 21

22 Ann.mänskligtPresentera(); Ralph.mänskligtPresentera(); Låt oss ta en närmare titt på programmet: Manniska RW = new Manniska(); Manniska AMS = new Manniska(); Nya instanser av objekt (klasser) kan vi alltså skapa med kommandot new. Då exekveras konstruktorn för den önskade klassen, och variabelnamnet (här RW och AMS) börjar peka på (referera) till den nya instansen. Det är med hjälp av denna referens som vi därefter kan nå den nya instansen. Principen är helt samma som hos arrays och arraynamn - det är ju där som du redan har stött på kommandot new. Java hittar själv den önskade klassen, bara den finns under samma område som programmet Manniskotest.java. Vi behöver inte exportera klassen eller dylikt. RW.namn = "Ragnar"; AMS.namn = "Annamari"; Här får våra nya instanser namn - konstruktorn för klassen Manniska har ju lämnat dom tomma. RW.presentera(); AMS.presentera(); Här anropar våra nya instanser sin metod presentera. Observera, att fast jag bara skapat två instanser direkt ur klassen Manniska, så räknas också alla våra elever och lärare som människor, eftersom det i konstruktorn för människoklassen står följande: Manniska() { namn = ""; antal++; // en ny människa till har skapats Java II med Annamari, närpass 3: Objektorienterad design 22

23 Således, trots vad Franzén säger, gäller konstruktorn i superklassen också i delklasserna. Varje lärare och varje elev är en människa, och räknas till antalet människor. I programmet ovan har vi alltså följande objekt (eller instanser av objekt): variabelnamn: AMS RW Ralph Paul Ann Bo Carin klass: Manniska Manniska Larare Larare Elev Elev Elev Variabelnamnen ovan är pekare, likadana referenser som vi har för arrays. Situationen i programmet ser alltså följande ut: AMS RW Ralph Paul Ann Bo Carin Om du börjar skriva kommandon typ Ann = Bo, då börjar båda pekarna peka på Bo, och vi tappar bort stackars Ann. Java II med Annamari, närpass 3: Objektorienterad design 23

24 Kurs.java import java.io.*; import javagently.*; class Kurs { // instansvariabler - varje instans av ett objekt har // dessa int kurskod, antal; String kursnamn; Larare examinator; Elev [] deltagare; // konstruktorer - dessa sker när vi skapar nya instanser // av denna klass Kurs () { antal = 0; deltagare = null; Kurs(int kod, String namn) { kurskod = kod; kursnamn = namn; antal = 0; deltagare = null; examinator = null; Här definierar vi ett objekt (en klass) kurs. Varje kurs har följande egenskaper: Kurs - kurskod (int) - antal (int) - kursnamn (String) - examinator (Larare) - Deltagare (Elev [], dvs. en array av Elever) Java II med Annamari, närpass 3: Objektorienterad design 24

25 En Kurs har två konstruktorer: en tom, och en som vi kan använda oss av ifall vi känner till kurskoden och kursnamnet. Låt oss se hur vi kan skapa kurser i ett (rätt så komplicerat) program: Kurssystem.java import java.io.*; import javagently.*; class Kurssystem { /* Klassen Kurssystem exemplifierar nedärvning och polymorfi; klasserna Larare och Elev utvidgar Manniska. Elementär pekarhantering kommer med. */ public static void main (String [] args) throws IOException { BufferedReader in = Text.open(System.in); int antal, num, svar; String namn; Elev [] årskurs; Larare RW = new Larare(); Larare AMS = new Larare(); RW.namn = "Ragnar Wikman"; RW.titel = "lektor"; AMS.namn = "Annamari Soini"; AMS.titel = "timlärare"; System.out.println("\n"); RW.presentera(); AMS.presentera(); System.out.println("\n"); Kurs Intro = new Kurs(6551, "Introduktion till Informationsbehandling"); Kurs Java = new Kurs(6567, "Grundkurs i Programmering/Java"); Intro.examinator = RW; Java.examinator = AMS; Text.prompt("Hur många elever i denna årskurs? "); antal = Text.readInt(in); årskurs = new Elev [antal]; Intro.deltagare = new Elev [antal]; Java.deltagare = new Elev [antal]; for (int i = 0; i < antal; i++) { Text.prompt("Ge matrikelnummer: "); num = Text.readInt(in); Text.prompt("Ge namn: "); namn = in.readline(); årskurs[i] = new Elev(num, namn); Java II med Annamari, närpass 3: Objektorienterad design 25

26 // Registreringen börjar: for (int i = 0; i < antal; i++) { Text.prompt(årskurs[i].namn + ", deltar du i intro? 0 (nej) eller 1 (ja): "); svar = Text.readInt(in); if (svar == 1) { årskurs[i].deltar(intro); // antal deltagare på kursen ökas med 1 Intro.deltagare[Intro.antal - 1] = årskurs[i]; // arrayn börjar från 0 Text.prompt(årskurs[i].namn + ", deltar du i java? 0 (nej) eller 1 (ja): "); svar = Text.readInt(in); if (svar == 1) { årskurs[i].deltar(java); Java.deltagare[Java.antal - 1] = årskurs[i]; // Dags att kolla läget: System.out.println("\n\nÅrskursen"); System.out.println("======================================================\n"); for (int i = 0; i < antal; i++) { System.out.println(årskurs[i].namn + " " + årskurs[i].matr + " tar: " ); for (int j = 0; j < årskurs[i].antalkurser; j++) System.out.println(årskurs[i].kurser[j].kursnamn); System.out.println(); System.out.println("\n\n" + Intro.kursnamn + " " + Intro.kurskod + " av " + Intro.examinator.titel + " " + Intro.examinator.namn); System.out.println("======================================================\n"); for (int i = 0; i < Intro.antal; i++) { System.out.println(Intro.deltagare[i].namn + " " + Intro.deltagare[i].matr); System.out.println("\n\n" + Java.kursnamn + " " + Java.kurskod + " av " + Java.examinator.titel + " " + Java.examinator.namn); System.out.println("======================================================\n"); for (int i = 0; i < Java.antal; i++) { System.out.println(Java.deltagare[i].namn + " " + Java.deltagare[i].matr); Java II med Annamari, närpass 3: Objektorienterad design 26