Arv och polymorfi. Lite terminologi; Basklass eller superklass: En klass som fungerar som bas för vårt arv. Vi skapar nya klasser utifrån den.

Transkript

1 Arv och polymorfi Arv och polymorfi är två centrala begrepp i objektorientering. Arvsmekanismen innebär att vi kan skapa nya klasser utifrån redan existerande klasser. Man gör detta med hjälp av nyckelordet extends. Syftet med detta är att skapa nya klasser som har alla den gamla klassens egenskaper samt några nya. Alternativt kan man förändra den gamla klassens beteende genom att byta ut vissa delar i den. Polymorfi betyder att en metod är mångformig, att den finns i många upplagor och att Java under programmets gång väljer rätt variant. Lite terminologi; Basklass eller superklass: En klass som fungerar som bas för vårt arv. Vi skapar nya klasser utifrån den. Härledd klass eller subklass: En klass som skapas från en basklass. Överlagrad (overloaded) metod: En metod som finns i många varianter. Alla varianter har olika signatur och det är kompilatorn som väljer. Exempel på sådana metoder är println. Överskuggad (overridden) metod: En metod med samma namn och samma signatur som en annan metod. De måste finnas i olika klasser i en familj av basklass och härledda klasser. Java väljer vid programkörning vilken metod som ska användas. Arvshierarki: En basklass och ett antal härledda klasser. har-en relation: Ett objekt innehåller något annat objekt, exempelvis innehåller ett tänkt bilobjekt fyra stycken hjulobjekt. är-en relation: Ett objekt som härleds från en basklass är samma sort som basklassen. En bil är ett fordon i en tänkt hierarki. Arv och polymorfi 26 March Arv och polymorfi 26 March Javas grafiksystem bygger i hög grad på arv. När vi skriver import java.awt.*; import extra.*; public class Ex1 extends Frame { String s; Font f= new Font("SansSerif", Font.BOLD, 24); public Ex1(String s) { this.s = s; setsize(400,400); setvisible(true); settitle("en frametitel"); setbackground(color.white); public void paint(graphics g) { g.setcolor(color.green); g.drawline(0,0,400-1,400-1); g.drawrect(0,0,400-1,400-1); g.setfont(f); g.drawstring(s,50,200); g.setcolor(color.blue); g.fillrect(50,50,200,100); g.setcolor(color.red); g.drawoval(150,170,100,200); Nu har vi skapat en härledd klass Ex1 med Frame som basklass. Alla objekt av typen Ex1 är också en Frame. De har alla egenskaper som en Frame har. Dessutom har de: Egna attribut som inte finns i Frame En egen konstruktor En egen överskuggande paintmetod Notera att är-en relationer inte är ömsesidiga. En Frame är inte nödvändigtvis ett objekt av typ Ex1. Vi säger att Ex1 är en specialiserad variant av Frame, den kan allt som Frame kan och lite till. På så sätt kan vi utnyttja basklasser och anpassa dem till våra ändamål. public static void main(string[] args) { Ex1 e; if (args.length==0) e = new Ex1("nil"); else e = new Ex1(args[0]); Std.out.print("Tryck return när du sett nog "); Std.out.flush(); int i = Std.in.readChar(); System.exit(0); Arv och polymorfi 26 March Arv och polymorfi 26 March

2 När du ska instansiera objekt av typen Ex1 kan du göra Ex1 e = new Ex1( Hejsan ); men lika gärna Frame e = new Ex1( Hejsan ); Varför. Kom ihåg att alla objekt av typ Ex1 också är av typ Frame. Frame är härledd från Window som är härledd från Container som är härledd från Component som är härledd från Object! Hur blir det med metoderna. Vad händer med e.paint(...) (som vi aldrig gör!!) Det blir rätt metod, nämligen den i Ex1. Varför? För att metoderna är polymorfa och java väljer rätt metod automagiskt. Vad lär vi oss av detta? Man kanske skulle valt nån annan kurs? Använd alltid metoder för att komma åt detaljer i objekt, inte publika attribut!!!! Component e = new Ex1( Hejsan );//OK Blir det nån skillnad? Ett exakt likadant objekt skapas. Blir det nån annan skillnad? Ja det blir det. Om du utifrån vill komma åt attributen i objektet e, dvs e.s eller e.f så kommer kompilatorn inte att hitta dem om referensen inte är av rätt typ (Ex1 här). Betyder det att de inte finns? Nej, bara att kompilatorn inte vet nåt bättre. Arv och polymorfi 26 March Arv och polymorfi 26 March Finns det nån vits med att ange bastypen istället för den mer specifika Ex1? Nej inte här, men i andra fall finns det det. Vi kan vilja skapa strukturer som är inhomogen, t. ex. en array av olika sorts objekt. Då skapar vi en array av basklasstypen och kan sedan lagra alla typer av härledda klasser. Java har en universell basklass Object, som alla klasser härletts från. Vi kan alltså göra en array av Objects och i den lagra vad som helst (utom de primitiva bastyperna). Fråga: Om vi nu lagrar en massa olika saker i en array, hur ska vi sen veta vad det är när vi hämtar det? Vi kan använda operatorn instanceof för att kontrollera typen av ett objekt. Den är sann om testat objekt är av angiven typ eller någon härledd klass till detta. Object [] a = new Object[200];.. // fyll arrayen. if (a[0] instanceof Ex1)... // det var ett sånt objekt! Arv och polymorfi 26 March Arv och polymorfi 26 March

3 Antag nu att vi själva vill bygga en modell av geometriska objekt av olika form, exempelvis kuber, sfärer och pyramider. Vi kan då göra något sånt här: public class Geom { private double x,y,z; // position private double sx, sy, sz, //storlek private int typ; // typ av objekt public Geom() {... Nu kan man ska objekt av denna typ och arbeta med dem. Om vi nu vill beräkna volymen av ett objekt så adderar vi metoder volym i klassen. public double volym() { switch (typ) { case 1: // beräkna för sfären case 2: // beräkna för pyramiden case 3: // beräkna för kuben returnera volymen Detta ser ju bra ut. Arv och polymorfi 26 March Arv och polymorfi 26 March Vilka problem kan en sån här design ge? Storlek måste anges med 3 tal, fast en sfär bara behöver ett tal. Vi måste ha en typ som vi anger typ av objekt. Vi måste ha en test på objektypen så fort vi gör något som är olika för olika objekt. Vad händer om vill definera en ny sorts objekt? Vi måste definiera ett nytt värde för typ-attributet. Vi måste ändra koden på alla ställen där vi använder typen. Blir väldigt lite modulärt. Arv och polymorfi 26 March Arv och polymorfi 26 March

4 Kan vi då göra nåt bättre? (sk retorisk fråga) Vi skapar en arvshierarki istället!! Först gör vi en basklass som innehåller att gemensamma detaljer. Sen gör vi härledda klasser, en för varje sorts objekt som innehåller de specifika delarna. Voffö då då? Vad är då gemensamt? De flesta metoder är gemensamma Position är lika för alla sorters objekt. Storlek kan ju anges på lite olika sätt så det lägger vi i de härledda klasserna. Då blir det så här Vi slipper typ-attributet och vi slipper testa på och vi kan enkelt skriva nya härledda klasser om vi behöver utan att skriva om nåt gammalt. Arv och polymorfi 26 March Arv och polymorfi 26 March public class Geom { private double x,y,z; // position... public void flytta ( double dx, double dy, double dz) { x += dx; y+=dy; z+=dz; public double volym() {? Hur gör vi då? Man kan ju alltid returnera noll. Vidare frågeställning: Är det nån mening att skapa objekt av denna klass? Om vi tänker en stund så inser vi nog att sådana objekt inte är så värst meningsfulla. Nu blev det lite problem här. Vad ska stå i volymmetoden? Vi vet att detta är ett geometrisk objekt men vi har bara en position, inget mer. Arv och polymorfi 26 March Arv och polymorfi 26 March

5 Eftersom vi tycker så så gör vi så här: public abstract class Geom { protected double x,y,z; // position public Geom() { x = y = z = 0; public Geom(double xp, double yp, double zp) { x = xp; y = yp; z = zp;... public void flytta ( double dx, double dy, double dz) { x += dx; y+=dy; z+=dz; Vad fick vi nu då? Vi har skapat en abstrakt basklass, men en eller flera abstrakta metoder. Det betyder att: Vi INTE kan skapa objekt av denna klass, den är inte instansierbar. Vi måste skriva metoden volym i alla härledda klasser. Är det nån vits med en icke-instansierbar klass? Ja, den funkar som basklass! Åtkomligheten protected betyder att härledda klasser kommer åt attributen. public abstract double volym(); Arv och polymorfi 26 March Arv och polymorfi 26 March Nu kan vi skriva public class Sfär extends Geom { private double radie; public Sfär() { super(); // Geoms konstr. radie = 1; public Sfär(double xp, double yp, double zp, double r) { super(xp,yp,zp); radie = r; Nu kan vi naturligtvis göra Sfär s = new Sfär(); men lustigt nog också Geom s = new Sfär(); Hur kan vi instansiera Geom? Det fick vi ju inte! Gör vi ju inte ju! Tänk! I själva verket är det sista skrivsättet att föredra eftersom vi då tydligt säger att vi gör ett geometriskt objekt som är en sfär.... public double volym() { return 4.0*Math.PI*radie* radie*radie/3.0; Nu har vi skapat en härledd klass till Geom som beskriver en Sfär. Arv och polymorfi 26 March Arv och polymorfi 26 March

6 Vi kan nu göra en härledd klass till: public class Box extends Geom { private double b,d,h; public Box() { super(); // Geoms konstr. b=d=h=1; public Box(double xp, double yp, double zp, double b, double d, double h) { super(xp, yp, zp); this.b = b; this.d = d; this.h = h;... Nu kan vi skapa geometriska objekt om vi vill. Exempelvis så här import extra.*; public class GTest { private Geom[] g = new Geom[10]; public static void main(string [] args) { for (int i =0; i < 10; i++) { Std.out.print( 1 = Sfär, 2 = Box ); int typ = Std.in.readInt(); if (typ == 1) g[i] = new Sfär(1, 2, -3, 2.3); else g[i] = new Box(1, -2, 5, 0.5, 1.2, 3.4); // ta fram ytan av alla objekt for (int i = 0; i < 10; i++) Std.out.println(g[i].volym()); public double volym() { return b*d*h; På samma sätt som tidigare. Arv och polymorfi 26 March Arv och polymorfi 26 March Nu har vi ett program som skapar tio geometriska objekt och lagrar dem i en array. Sen skriver vi ut volymen av alla objekten. Java väljer för varje anrop av volymsmetoden vilken av de två tänkbara metoderna som ska anropas. Det görs genom en kontroll av vilken sorts objekt som refereras. Metoden är polymorf! En Sfär ÄR EN Geom och kan användas överallt där en ett objekt av typen Geom förväntas Samma för Box. Om du har en objektreferens av typ Geom kan det vara en Sfär eller en Box, det vet du inte förrän när programmet körs. Det skulle i det generella fallet kunna vara en instans av basklassen också. En Sfär är INTE en Box. Vi kallar detta för sen bindning eller dynamisk bindning. Java bestämmer sig för vilken volymsmetod som ska användas först när programmet körs. Vi har också tidig binding eller statisk bindning som görs när programmet kompileras. Överlagrade metoder använder tidig bindning. Exempelvis bestämmer kompilatorn vilken variant av println som ska användas. Arv och polymorfi 26 March Arv och polymorfi 26 March

7 Detta har betydelse vid parametrar och vid tilldelning. Geom a = new Box(); // OK Box b = new Box(); // OK Box c = new Geom(); // Fel Box d = new Sfär(); // fel Geom e = new Sfär(); // OK Sfär f = new Sfär(); // OK Sammanfattningsvis: Arv kan användas på två olika sätt: Att fylla i och förändra befintliga objekt så att de beter sig på ett mer önskvärt sätt Att skapa en samling med olika specialiserade varianter av en gemensam bas. a = b; e = b; e = f; // OK // OK // OK f = e; // Njet f = (Sfär) e; //OK eftersom e // är en Sfär f = (Sfär) a; // passerar javac // men inte java, a // är inte en Sfär f = (Sfär) b; // Fel Regler: Tilldela uppåt i hierarkin OK Tilldela nedåt OK med typkonvertering om det är korrekt sorts objekt. Tilldela horisontellt aldrig OK. Arv och polymorfi 26 March Arv och polymorfi 26 March Interface, gränssnitt När vi använder lyssnare har vi sett att vi exempelvis gör: public class X extends Frame implements ActionListener { ActionListener är ett interface. Det är en samling deklarationer av metoder utan implementation. public interface ActionListerner { public void actionperformed(actionevent e); En implementation av ett gränssnitt anses också vara av samma typ som gränssnittet och kan användas där ett sånt efterfrågas. En klass kan bara ha en basklass men implementera hur många gränssnitt som helst. Det finns många interface i Java bl. a. för händelselyssnarna. Det gäller alltid att du måste implementera ALLA metoder i ett interface. Vissa lyssnare har många metoder, men du kanske bara behöver en av dem. För att förenkla arbetet definieras då Adapterklasser. Varför har vi detta? Java använder sådana för att kunna beskriva exakt hur gränssnittet mot något ser ut, exempelvis olika lyssnare. Däremot får du själv sedan fylla gränssnittet med innehåll, beskriva vad som ska hända. Detta gör du genom att implementera alla metoder i gränssnittet. Arv och polymorfi 26 March Arv och polymorfi 26 March

8 En Adapterklass är en implementation av ett interface. Alla metoder implementeras med tomma metoder, dvs metoder som inte gör något alls. Exempelvis public class MouseAdapter implements MouseListener { public void mouseclicked( MouseEvent e) { public void mouseentered( MouseEvent e) { public void mouseexited( MouseEvent e) { public void mousepressed( MouseEvent e) { public void mousereleased( MouseEvent e) { Nu kan du göra public class Musse extends MouseAdapter { private int x,y; public void mouseclicked( MouseEvent e) { x = e.getx(); y = e.gety(); Nu kan du i någon annan klass göra Musse m = new Musse(); addmouselistener(m); Du behöver ingen implements och du behöver bara skriva en metod. Du har skapat en härledd klass från adaptern. Vad kan detta vara bra för då? Arv och polymorfi 26 March Arv och polymorfi 26 March Du kan ju skriva MouseAdapter m = new Musse(); addmouselistener(m); också om du vill. Varför? För att basklassen alltid kan anges istället för en mer specialiserad. Parametern till addmouselistener ovan ska ju vara något som implementerar lyssnaren. Det gör vi ju fast lite indirekt. Du kan alltså också skriva: MouseListener m = new Musse(); addmouselistener(m); Vi kan också skriva MouseAdapter m = new MouseAdapter() { private int x,y; public void MouseClicked( MouseEvent e) { x = e.getx(); y = e.gety(); ; Vad menas? Vi har skapat en anonym subklasstyp som härleds från MouseAdapter. Objektet m är alltså ett objekt härlett från MouseAdapter, men typen har inget namn. Används när vi bara vill utnyttja det hela en gång som här. Arv och polymorfi 26 March Arv och polymorfi 26 March

9 För finliraren: Vi kan göra en anonym instans av en anonym subklass också! Då gör vi: addmouselistener(new MouseAdapter() { private int x,y; public void MouseClicked( MouseEvent e) { x = e.getx(); y = e.gety(); ; ) Nu har vi en instans som inte heter nåt av en klass som heller inte heter nåt men som är härledd från MouseAdapter. Denna instans fungerar som lyssnare och behöver inget namn, bara en referens. Arv och polymorfi 26 March