Hejs!

Har förstått att interface ställer krav på klassen som implementerar den
Att man MÅSTE implementera de metoder som finns i interfacet.
Är det tänkt att fungera som ett sorts multipelt arv , som i c++ eller ??
eftersom man kan implementera flera olika interfaces i en klass.

Kan bara inte komma på nåt riktigt bra ex , där man skulle ha stort behov av
INTERFACE ???

Nån som kan ge ett bra exempel ??


//JOnas

Har själv inte riktigt full kontroll på interfacen men om man t.ex. har gjort någon form av collection där man kan peta in massa olika object och sedan göra save på collectionobjektet för att spara alla i collection.

Då måste ju alla dina andra object i collection ha en save-metod, och då kan det vara bra att implementera ett interface till de objekt. Då vet du att alla objekt som finns i din collection har en save-metod.

Sen vet jag inte om man kan göra så att alla object man petar in i sin collection måste ha implenterat ett visst interface annars får man ett exeption.

/ Jimmy

Eftersom man inte kan ärva från flera klasser i Java så använder man sig av interface. Man kan implementera flera interface i en klass samtidigt som man ärver från en annan. Och det stämmer att man måste definiera alla metoder från interfacet i klassen där man implementerat interfacet.


/A

Om du tänker dig att du skall bygga en plugin så är interfaces bra att att ha till hands. Du kan deklarera vilket interface du vill att en plugin skall stödja när du skriver huvudprogrammet och sedan exportera detta interface så att andra kan använda dessa i sina egna plugins.

Hej igen!

tack för alla svaren, men jag greppar fortfarande inte det hela ?

Skulle behöva ett praktiskt exempel tror jag.




//Jonas

Hej,

Att använda sig av interface är A och O i javaprogrammering, det är en väldigt stor del av språket. Ett bra exempel kan vara att titta på hur JDBC är uppbyggt av interface som måste implementeras av olika databasleverantörer. Oavsett om du nyttjar MS SQL Server, Oracle, mysql eller någon annan databashanterare så använder du exakt samma interface...men med annorlunda implementation av dem bakom vilken du som programmerare inte behöver känna till. Det är likadant med JAXP för att hantera XML. Du programmerar mot ett interface och kan välja vilken implementation du vill använda, t ex xalan/xerces eller kanske en annan komersiell produkt.

Titta också t ex på Collection interfacet som finns i java. Detta implementeras av både ArrayList och Vector. Om en metod t ex returnerar en Collection så behöver du inte veta vad som finns bakom...om det t ex är en Vector eller ArrayList. Du använder den på exakt samma sätt i vilket fall eftersom klassen (ArrayList/Vector) implementerar interfacet Collection och du behöver bara känna till Collection:s interface metoder. Du kan alltså använda interfacets hasNext() metod och behöver inte använda en for loop som man brukar göra för att iterera en Vector eller ArrayList.

Hoppas att det klarnar något annars får du hojta till så ska jag visa dig ett kanske lite mer enklare exempel.

/klas

Jag kan inte svara för Vlund, men för mig har det klarnat en hel del... ;)

Tack så mycklet Klas, för det utförliga exemplet...

/ Jimmy

Hej åter igen!

Exemplet var ju bättre, klarnade en del, men har du nåt enkelt
exempel till övers så får du gärna delge det.


//Jonas

Vet inte om jag kan förklara det mycket enklare...jag tror att det kommer att börja klarna för dig ju mer du jobbar med java. Med hjälp av ett interface bygger man ju upp en typ av fasad framför de objekt som implementerar dem. Man behöver inte veta hur de implementerande objekten ser ut eller hur de egentligen fungerar. Man förenklar väldigt. Skulle implementationen bakom interfacet förändras så kommer ju inte det att påverka den som använder interfacet, såvida inte metoder i interfacet har förändrats.

Jag pratade om jdbc i mitt förra inlägg. Detta var relevant för mig eftersom jag precis skrivit en jdbc för xml filer. Detta gör att vi i det system vi nu bygger inte behöver skriva några specialklasser som jobbar med DOM eller SAX..kan man tro...men detta är ju precis vad jag gör. Jag implementerar interface som t ex Connection, ResultSet, Statement, PreparedStatement osv. med hjälp av SAX och DOM men den som använder Interfacen har ju inte en aning om hur koden ser ut bakom. De "ansluter" till xml:en på precis samma sätt som de gör då de skapar en Connection mot t ex MS SQL Server. Vill man sedan byta ut xml:en mot t ex en relationsdatabas gör man enbart detta i en config fil...man behöver inte överhuvudtaget förändra eller kompilera om koden.

Kanske inte ett enklare exempel men i alla fall...

/Klas

Ok då gör jag ett försök att förklara det hela :-)

Ett Interface är ett kontrakt, ett kontrakt där du lovar att implementera de metoder som interfacet definierar. Hur du implementerar dessa metoder bryr sig inte kontraktsmakaren (den som skapade Interfacet) om, det är upp till dig. Det viktiga är att ni (du och kontraktsmakaren) är överens om hur ni ska kommunicera för att få uppgiften gjord. Det är kontraktsmakarens uppgift att tala om när det ska ske, genom att anropa de funktioner som finns i interfacet, och det är din uppgift att utföra det.

Du kan skapa många klasser som uppfyller detta kontrakt (implementerar interfacet) och andra programmerare kan göra samma sak.

Ett exempel. Du har skapat en datastruktur (t ex en array, länkad lista, collection, stack, ...) och du vill att den som använder datastrukturen ska kunna sortera den. Problemet är att du inte vet vad användaren ska lagra i din datastruktur, så du kan inte själv skriva hela sorteringsalgoritmen. Personnummer sorteras annorlunda än adresser o s v. Nästan alla sorteringsalgoritmer utgår dock från parvis jämförelser av element så om du bara kan få information om huruvida element nr x är större, lika med eller mindre än element nr y så har du all information du behöver för att kunna sortera hela din datastruktur.

Det är i detta läge som du skriver ett kontrakt (Interface) som användaren av din datastruktur ska använda, ett kontrakt som heter t ex IComparable som innehåller en metod som heter Compare. Compare-metoden tar två argument som motsvarar indexen på de två element som ska jämföras och som returnerar -1,0 eller 1 beroende på vilket element som är störst.

Användaren av din datastruktur skapar således en klass som implementerar ditt interface (IComparable), och mer specifik metoden Compare. Användaren instansierar ett sådant objekt och skickar med det till din datastruktur så att du när som helst kan anropa Compare-metoden som användaren skrivit. På detta sätt behöver du inte veta hur användarens data sorteras, det överlåter du åt den som har den kunskapen/informationen.

Ett pseudokod exempel med en array (inget särskilt språk) :

Först interfacet :

public Interface IComparable
{
public int Compare(int x,int y)
}

Sedan din datastruktur :

public class SortableArray
{
object[] theArray; // Arrayen som innehåller användarens data
// Vi vet inte vilken typ datan har eller hur det sorteras

// Användaren av din datastruktur anropar sort-metoden när han/hon vill
// ha en sortering och bifogar ett objekt som implementerar interfacet
// IComparable och dess Compare-metod. Enkel bubbelsortering...
public void Sort(IComparable sortHandler)
{
int i,j;

for (i=0;i<theArray.length-1;i++)
for (j=i+1;j<theArray.length;j++)
if (sortHandler.Compare(i,j)>0) // Anropa Compare-metoden!
Switch(i,j) // Byt plats på element i och j
}
}

Nu över till användarens kod :

Användaren av din klass måste skapa en klass som implementerar interfacet IComparable:

public class MySortHandler : IComparable
{
public int Compare(int x,int y)
{
// Jämför element x med element y och returnera -1, 0 eller 1
}
}

För att sortera data:n kan användaren nu skriva :

SortableArray mArray=new SortableArray();
// fyll på data i mArray
MySortHandler mSortHandler=new MySortHandler();

mArray.Sort(mSortHandler) // Anropa Sort-metoden med en SortHandler



Några kompletteringar :

1) Notera att du inte behöver veta hur elementen jämförs och att användaren inte behöver veta vilken sorteringsalgoritm som används (bubble, quicksort, ...)

2) Metoden Compare skulle kunna ta parametrar av typen Object eller liknande som klarar alla datatyper och Sort-metoden skickar då i st för indexen in själva objekten. Nackdelen är att man inte får full typkontroll med datatypen object (plus boxing/unboxing)

3) Om användaren vill lagra ett helt annan typ av objekt i din datastruktur och sortera den så skapar han/hon bara en ny SortHandler som gäller för detta objekt.

4) Om användaren vill sortera elementen i fallande ordning i stället för stigande så skapar han/hon bara en ny SortHandlerReverse som också implementerar IComparable men som returnerar -1 i st för 1 och tvärtom. Din datastruktur behöver inte skrivas om för detta.

Hoppas att det klarnade något, det tog en stund att skriva detta :-)

/Per Hultqvist

Hej Per!

Man tackar ödmjukast för den fina förklaringen och det
trevliga exemplet. Nu börjar polletten att röra sig ;).
Om man tittar i javaböcker så skrivs det inte så ingående i hur
de fungerar tyvärr, men som tur var finns det ju sympatiska
killar som DU !

tusen, tusen

//Jonas

Man kan säga att ett interface beskriver vad en klass kan göra. Om en klass ärver en annan, kan man säga att klassen är av samma typ som den ärvda.

/Jörgen