725G61 - Laboration 6 Objektorientering, modellering och arv. Johan Falkenjack

Transkript

1 725G61 - Laboration 6 Objektorientering, modellering och arv Johan Falkenjack November 27, 2013

2 1 Inledning I labb 5 tittade vi på grundläggande objektorientering och skapade en första klass som vi kunde instansiera. Vi använde dock objektorientering för att representera en datastruktur, vilket väl i all ärlighet inte är så spännande (oavsett vad vi med datavetenskaplig bakgrund försöker lura i oss själva). I den här labben ska vi titta på hur objektorientering kan användas för att modellera världen. Istället för att ha en klass som representerar något så abstrakt som mängder av heltal ska vi hantera människor i ett enkelt informationssystem. Vi ska också gå vidare och titta på några mer avancerade objektorienterade koncept såsom arv och överlagring. 2 Inkapsling och accessormetoder I förra labben pratade vi som hastigast om publika och privata variabler. En grundprincip i Java är att man alltid ska skydda sina variabler så mycket som möjligt, om de inte måste vara publika bör de vara privata - det här kallas för principen om inkapsling inom objektorienterad programmering. En klass eller ett objekt ska alltså så långt det är möjligt själv få styra över värdena på sina variabler, och om det inte är absolut nödvändigt bör man inte tillåta att någon annan klass direkt får komma åt och läsa eller ändra värdet på dem. I många fall behöver trots det andra klasser, t.ex. kanske main-metoden för programmet, komma åt värdet på variabler. Då är det ändå bättre att göra sina variabler privata och istället använda så kallade accessormetoder för att komma åt dem. Accessorfunktioner kallas ofta för getters och setters, för det är precis vad de gör, de hämtar (get) och de tilldelar (set) värden. Utan att påpeka det skapade vi faktiskt getters i labb 5. Både getsize(), som hämtade storleken av en mängd, och instances(), som returnerade antalet instanser av MySet som skapats, är så kallade getters. I det generella fallet har getters och setters ofta namn i stil med getsize() och setsize(), där "size" är namnet på variabeln som hanteras. Om den privata variabel man hanterar är en boolean använd dock ofta is, t.ex. isactive() för att hämta värdet från varaibeln active som är en boolean. Detta gör koden mer lättläst då den i större utsträckning kan läsas som vanlig engelsk text. Anledningarna till att man skapar accessorfunktioner (getters och setters), istället för att ha variabler publika eller helt oåtkomliga, är många. Den mest uppenbara är kankse att man kan vilja lägga till felhantering och filter i sin set-metod, den som manipulerar värdet på variabeln, för att inga felaktiga data ska kunna skickas in. Till exempel vill man kanske inte att en instansvariabel som representerar ett namn ska kunna bestå av enbart siffror. För att då kunna garantera att en textsträng av enbart siffror aldrig tilldelas namn-variabeln används en set-metod som innehåller den felhanteringen, d.v.s. kontrollerar innehållet i textsträngen innan tilldelningen görs. En annan anledning är att man kanske inte alltid vill tillåta explicit ändring av en variabel utifrån, även om man vill kunna läsa den - då skapar man helt enkelt ingen set-metod. Det var fallet 1

3 med båda våra getters i labb 5, size kunde t.ex. bara ändras genom att lägga till eller ta bort element och instances() ändrades bara inifrån konstruktorn när nya instanser skapades. Det betydde att varken size eller noofinstances kunde få ett felaktigt värde, om inte vi gjort fel när vi skapade klassen förstås. För get-metoder finns inte lika uppenbara skäl till att ha en specifik metod, istället för att läsa direkt från variabeln, men för att kunna skydda variabeln från att ändras utifrån måste vi göra den privat, och det får helt enkelt konsekvensen att den heller inte kan läsas utan att vi har en specifik metod för det. I vissa fall kan man dock vilja läsa en variabel i ett annat format än den finns lagrad i internt, då kan get-metodern även användas för att omvandla värdet till en specifik datatyp eller till ett visst format. Till exempel skulle vi kunna ha två olika get-metoder för en variabel som innehåller en persons alla förnamn, en som returnerar strängen precis som den finns lagrad i vår variabel, t.ex. "Eva Maria" för en person med två förnamn, medan den andra get-metoden istället returnerar en String[] där namn-strängen delats upp och lagts i en array, t.ex. {"Eva","Maria"} i vårt exempel. 2

4 UPPGIFT 6.1 Skapa en klass Person och lägg den i ett lämpligt paket som du själv namnger. Klassen ska ha tre privata instansvariabler, surname (efternamn) och givenname (förnamn), som båda är strängar, samt birthyear som är ett heltal. Getters och setters skall finnas för samtliga variabler. (Notera att Eclipse har en genväg för att generera getters och setters för en klass, när ni har skapat instansvariablerna - använd gärna den, men tänk på att ni kan behöva ändra koden som genereras för get- och set-metoderna, t.ex. för att lägga till felhantering nedan.) Klassen ska också ha två publika konstruktorer. En som inte tar några argument och inte tilldelar några av instansvariablerna något värde, och en som tar förnamn, efternamn och födelseår som argument och tilldelar dessa värden till respektive instansvariabel. Lägg sedan till lämplig felhantering i alla tre set-funktionerna. Ni behöver inte täcka alla eventualiteter, men se till att åtminstone kontrollera något som ni tycker är orimligt i varje set-metod, t.ex. kan det vara lämpligt att kasta ett undantag om man försöker ge någon ett namn som börjar på en siffra. Skapa till sist en klass PersonUI som bara innehåller en main-metod. Just nu ska ni bara använda den här klassen, och dess main-metod, för att testa er Person-klass, men vi kommer lägga till fler saker i PersonUI lite senare i labben, då kan ni kommentera bort (eller radera) test-koden som ni skriver i main-metoden i den här uppgiften. I main-metoden skapar ni nu ett par objekt, instanser av klassen Person, genom att anropa de två olika konstruktorerna. Testa sedan att använda era get- och set-metoder för att hämta och ändra värden. Var noga med att testa de olika villkoren, d.v.s. felhanteringen, ni har lagt in i era set-metoder, d.v.s. om ni har lagt till en kontroll för att förhindra att födelseår tilldelas ett negativt tal, testa att skriva en rad kod som försöker ändra födelseåret i en av era person-instanser till ett negativt tal och kontrollera att ni faktiskt får det resultat ni förväntar er, t ex ett undantag. 3

5 UPPGIFT 6.2 Nu ska vi modifiera vår klass PersonUI lite, du kan börja med att kommentera ut test-koden som du lade till i main-metoden i förra uppgiften. PersonUI ska ha en privat klassvariabel, YEAR, som innehåller det aktuella årtalet (2013 i skrivande stund). Variabeln ska vara en konstant, d.v.s. deklareras med hjälp av nyckelordet final och gärna ha ett namn som bara består av versaler (det sistnämnda är inte nödvändigt, men man använder oftast versaler för en konstant för att det ska bli lätt att se att det här är just en konstant när man använder variabeln senare i koden). Klassen PersonUI ska också ha en metod, age(), som tar ett Person-objekt som argument, hämtar ut födelseåret ur objektet och använder det aktuella året för att beräkna och returnera personens ålder (ett heltal). Använd sedan klassen Scanner i main-metoden för att läsa in förnamn, efternamn och födelseår för en person från användaren, och skapa ett nytt Person-objekt med hjälp av de inlästa värdena. Tänk på att ni alltid behöver ha någon felhantering när ni läser in data från användaren. Kan ni använda er av den felhantering ni skapade i set-metoderna i förra uppgiften? Till sist, låt er main-metod beräkna personens ålder m.h.a. metoden age() och skriv sedan ut åldern på skärmen. 4

6 UPPGIFT 6.3 Skapa en ny klass, Course, med instansvariablerna courseid (en sträng i stil med t.ex. "725G61"), coursename (en sträng, t.ex. "Programmering, grundkurs") och ap (academic points, d.v.s. hur många hp kursen är på, ett heltal). En konstruktor som tar in och tilldelar värden för samtliga dessa tre instansvariabler ska finnas, samt getters för alla. Kurser byter dock aldrig namn, kurskod eller antal hp så setters ska inte finnas (LiUs policy är generellt sett att vid stora ändringar skapa en ny kurskod osv.). Klassen Course ska också ha en privat klassvariabel courses som är en ArrayList<Course> som innehåller alla kursobjekt som skapats under tiden programmet körts. Dessa ska automatiskt läggas till i ArrayList:en när nya Course-objekt skapas. (Tips: Kom ihåg hur vi räknade hur många mängder vi skapat i labb 5.) Skapa också en publik klassmetod getcourses() som returnerar listan courses. Testa din nya klass genom att lägga till kod i main-metoden i PersonUIklassen. Skapa några (minst 4-5 stycken) kursobjekt och hämta sedan listan på kurser med hjälp at getcourses() och skriv ut listan på skärmen. Du ska alltså inte behöva manipulera courses på något sätt från PersonUI-klassen utan listan ska innehålla alla nya objekt så snart dessa har skapats med hjälp av konstruktorn. 3 Arv Arv är en av de viktigaste och mest kraftfulla konstruktionerna i objektorientering. Arv beskriver relationer mellan klasser. En sådan relation är t.ex. relationen mellan katter och tigrar. Alla tigrar är katter, men inte alla katter är tigrar. Skulle vi vilja modellera alla djurarter som Java-klasser (gud förbjude, det sägs finnas rätt många olika arter) skulle vi då t.ex. ha en klass Cat som t.ex. beskrev att katter har fyra ben och svans medan vi skulle ha en klass Tiger som ärvde av Cat. Tiger skulle då inte behöva ha koll på de fyra benen och svansen, det är givet av att alla tigrar är katter, men skulle behöva lägga till hantering av antal ränder. Man kan ha arv i flera nivåer, t.ex. Mammal, Quadriped, Cat, Tiger, d.v.s. Däggdjur, Fyrfoting, Katt, Tiger. 3.1 Automatiskt arv Alla klasser i java ärver till syvende och sist från klassen Object (java.lang.object) som ligger i toppen av arvshierarkin i Javas standardbibliotek. Om man inte explicit säger vilken existerande klass en ny klass ska ärva av så kommer den ärva direkt av Object. Slå gärna upp klassen java.lang.object (i Javadoc för standardbiblioteket) och läs igenom dess beskrivning. Slå även gärna upp några 5

7 andra klasser som ni är bekanta med, och titta på var någonstans i arvshierarkin dessa klasser finns - det kan ni se genom den "trädstruktur" som visas allra först på deras Javadoc-sida. Till exempel kan ni se att klassen String ärver direkt från Object, medan ArrayList har flera klasser mellan sig och Object (AbstractList och AbstractCollection) i hierarkin. Klassen Object har ett antal metoder som alla klasser som ärver av den, d.v.s. alla klasser vi någonsin skapar, direkt kan använda sig av, om de, eller en klass på vägen upp i hierarkin, inte överskuggar, d.v.s. implementerar en egen version av metoden. För att överskugga en metod skapar vi helt enkelt en metod med samma signatur (samma namn och likadan parameterlista) samt returtyp i vår klass, som den metod vi vill överskugga. Metoden bör lämpligen göra "ungefär samma sak" som original-metoden (i superklassen) som vi överskuggar, så läs gärna igenom dokumentationen för metoden ni vill överskugga för att förstå ungefär hur metoden ska bete sig, men sedan skapar vi alltså en anpassad variant av metoden genom att skriva en egen metodkropp. Vi ska undersöka detta i nästa uppgift genom at överskugga metoden tostring(). UPPGIFT 6.4 Använd din main-metod i klassen PersonUI och skapa ett objekt av klassen Person, se till att objektet har både för- och efternamn samt födelseår. Anropa nu metoden tostring(), som returnerar en textsträng, på objektet och skriv ut resultatet på skärmen. Vad som har hänt är att vi anropat Object-klassens tostring() som bara skriver ut en minnesadress, d.v.s. referensen som finns lagrad i variabeln, men inte själva värdet på textsträngen. Känns det bekant? Detta är t.ex. vad som händer varje gång vi skickar en array till System.out.println() så ni kanske har stött på detta redan. För att få tostring() att bete sig mer som vi kanske förväntar oss, d.v.s. skriva ut information om vårt Person-objekt och inte bara en minnesadress, ska vi nu skapa en egen version av tostring(), speciellt anpassad för vår Personklass. Klassen Person ska alltså ha en publik metod som heter tostring(), som överskuggar den tostring() som ärvts från Object. Denna skall returnera en textsträng som innehåller informationen från de tre instansvariablerna i ett rimligt format, t.ex. "Förnamn Efternamn, årtal." eller "Efternamn, Förnamn, årtal." (där såklart "Förnamn", "Efternamn" och "årtal" har ersatts med värdena på de tre variablerna för det aktuella objektet). Kör samma kod som du använde i main-metoden i PersonUI i början av den här uppgiften igen. Nu ska utskriften inte längre bli en minnesadress, utan istället informationen från de olika instansvariablerna formaterat på det sätt som du betämt i din variant av metoden tostring(). 6

8 3.2 Ange arv i klassdeklarationen Vi såg i förra avsnittet att alla klasser automatiskt ärver av klassen Object. Vi pratade dock också om att ärva från andra klasser, t.ex. att Tiger kan ärva från Katt. Detta är något man kommer vilja göra ofta när man programmerar objektorienterat. För att ärva från en viss klass i Java används nyckelordet extends på följande sätt: 1 public class Tiger extends Cat { 2 //Meow... Sorry, I mean GROWL! 3 } Vid ett sådant arv så ärver Tiger alla egenskaper som Cat har. Om Cat t.ex. har en instansvariabel name så kommer även Tiger ha det utan att explicit behöva skriva koden för det igen, likandant med metoder. Detta sparar enormt mycket arbete och innebär att man inte behöver skriva samma kod flera gånger när man har flera klasser som påminner om varandra, men inte är exakt lika. Man säger att Tiger är en subklass till Cat som i sin tur är en superklass till Tiger, detta från de latinska begreppen sub (under) och super (över). UPPGIFT 6.5 Skapa en klass Student som är en subklass till Person. Student ska ha två instansvariabler, utöver de som ärvs från Person. Dels ett liu-id, en sträng i stil med abcde123, och dels en ArrayList<Course> som är en förteckning över de kurser en student läser. Nu kan det även vara lämpligt att ändra modifieraren private för alla instansvariablerna i Person till protected, som betyder att de direkt kan användas av instanser av subklasser (d.v.s. både instanser av Person men även Student som är en subklass till Person). Skapa en uppsättning kurser i main-metoden i PersonUI (kom ihåg att klassen ju själv ska hålla koll på alla skapade kurser). Skriv sedan en liten interaktionsloop som låter användaren mata in all information om en student (glöm inte felhantering - liksom tidigare behöver ni inte ta hänsyn till alla eventualiteter, men någon kontroll ska göras för varje värde), inklusive det som ärvs från Person, och sedan visar en lista med alla kurser och låter användaren välja en eller flera kurser att lägga till i studentens personliga kurslista. Tips: När kurserna listas är det smart att skriva ut vilket index i courses de ligger på, då kan denna siffra användas för att välja en kurs. Till sist, skriv ut all information om studenten som skapats på skärmen, inklusive de kursen som denne har i sin personliga kurslista. 7

9 3.3 Interface I Java kan en klass bara ärva från en annan klass direkt (som sagt ovan kan man dock sätta ihop arv i långa kedjor). Vi kan alltså bara ha en klass efter extends-kommandot. Ett sätt att komma runt detta i Java är att använda sig av interface eller gränssnitt, även om jag nästan aldrig hört den svenska termen användas. Ett interface är en mall som ställer vissa krav på en klass. Dessa krav yttrar sig genom instansvariabler som måste finnas och/eller metoder som måste implementeras för att interfacets krav ska vara uppfyllda. Vi kan tänka på ett interface nästan som ett kontrakt som vår klass lovar att uppfylla. Om vi ser att en klass implementerar ett visst interface som vi känner till, då vet vi också vilka variabler och/eller metoder vi kan anta att den har. I vårt exempel med djur kan vi prata om egenskapen att flyga. Det finns alla möjliga djur som kan flyga som inte är nära släkt med varandra och därför opraktiska att sätta ihop med vanliga arv. T.ex. är det lite orimligt att säga att fåglar ärver av fladdermöss eller tvärt om, då de förstnämnda är närmare släkt med dinosaurierna än med de sistnämnda. I det fallet kan det vara lämpligt att använda ett interface som hanterar flygförmågan. Om en viss djurart kan flyga kan vi i så fall säga att arten implementerar interfacet "flygförmåga", då vet vi kanske att arten (klassen) kommer att ha variabler såsom flyghastighet och vingspann som hör ihop med just flygförmåga. I Java finns mängder av inbyggda interface, d.v.s. gränssnitt som finns fördefinierade i Javas standardbibliotek. Gränssnitten hittar ni i standardbiblioteket precis som klasserna, men skillnaden är att gränssnitten ju inte innehåller någon egen kod som implementerar de variabler och metoder som beskrivs, utan ni måste själva implementera dessa för att de ska kunna användas - interfacet beskriver bara själva "kontraktet" som ska uppfyllas. Några av de interface man kan stöta på är t.ex. Serializable (ett interface som används när man vill kunna lagra hela Java-objekt på disk eller skicka Java-objekt över ett nätverk), Runnable (används när kod ska kunna köras i en egen tråd, om ni inte vet vad en tråd är så oroa er inte för det, det är överkurs) eller Comparable (används när man vill säga att objekt av klassen kan jämföras, t.ex. med varandra, och därför kan de sorteras). För att visa att en viss klass i Java implementerar ett visst interface används nyckelordet implements på följande sätt: 1 public class Bird implements Flying { 2 /*Code for the Bird-class, which 3 * needs to include all the variables 4 * and methods specified by the 5 * Flying-interface 6 */ 7 } En klass kan implementera flera olika interface, till skillnad från arv, där varje klass bara kan vara en direkt subklass till en annan klass. 8

10 Vissa interface kan, liksom vissa klasser, ha en typparameter. Tänk t.ex. på när vi skapar en ArrayList, då talar vi om vilken typ objekten ska ha som vi vill kunna lagra i vår lista genom att ange typen inom <> efter ArrayList, t.ex. ArrayList<Integer> för en lista med heltal. På liknande sätt kan även interface ha en typparameter. I uppgiften nedan kommer vi att stöta på just ett sådant inerface, nämlingen Comparable. När ni slår upp interfacet i Javadoc för standardbiblioteket så ser ni att det beskrivs som Comparable<T>, där T är typen av objekt som vi ska kunna jämföra med. I vårt fall vill vi kunna jämföra en person med en annan person, så vårt T kommer alltså att vara klassen Person. Detta anger vi direkt i klassdeklarationen när vi talar om att vår klass implementerar Comparable, d.v.s. vi skriver Comparable<Person> istället för bara Comparable. UPPGIFT 6.6 Modifiera klassen Person så att den implementerar interfacet Comparable (java.lang.comparable) för att kunna jämföra två personer med varandra. Eclipse kommer då kräva av er att ni lägger till en metod. Den metoden, compareto(), ska ta ett annat Person-objekt som argument och beräkna vilken person som kommer "först" i ordningen. Vad innebär då "kommer först" i vårt fall? Jo, om Person-objektet som skickats in har ett namn som kommer före det aktuella objektets i bokstavsordning (notera att strängar kan jämföras med sin egna compareto()-metod eftersom String också implementerar interfacet Comparable) ska -1 returneras, är namnen exakt lika ska 0 returneras och annars ska 1 returneras. Först ska ni jämföra efternamnen, men om dessa är samma ska förnamnen jämföras, bara om även dessa är exakt lika ska metoden returnera 0. Utöka sedan main-metoden i klassen PersonUI (det är okej att tillfälligt kommentera ut koden som ni använt för de övriga uppgifterna, men ta inte bort den - koden från uppgift 6.2 ska ni t.ex. återanvända i senare labbar) med en interaktionsloop som läser in och skapar 4 personer och lagrar dessa i en Person-array, d.v.s Person[]. Använd sedan Arrays.sort() för att sortera arrayen. Tack vare copareto() kommer arrayen förhoppningsvis vara korrekt sorterad nu. Ni behöver alltså inte explicit anropa compareto() någonstans, utan Arrays.sort() kommer automatiskt att använda den. Använd en loop för att skriva ut Person-objekten en gång före ni sorterar dem, samt en gång efter sorteringen för att kontrollera att sorteringen fungerat som förväntat. Testa att mata in personer som har samma efternamn, så att ni ser att jämförelsen fungerar även när endast förnamnen skiljer personerna åt. 9

11 4 Bonusuppgift Övning 6.1 Gå tillbaka och titta på labb 4 och se hur interaktionsloopen var designad. Skapa sedan en interaktionsloop för vårt system med kurser och studenter. Bra kommandon att ha är t.ex. kommandon som skapar studenter, skapar kurser, listar studenter, listar kurser, lägger till kurser i studentens lista etc. Tänk på att all inmatning ska ha lämplig felhantering. 10