Interface

Har en fundering som följt mig ända sen prog-certen och som inte vill lämna skallen på mig:

Det sägs ju att interface är en "elegant" lösning på det faktum att Java inte har multipelt arv (som t.ex C++). Min fråga är då: På vilket sätt då? Med interface ärver man ju egentligen inget, det är ju bara en speciell variant av en abstrakt klass mer eller mindre.

Att interface kan ha sina användningsområden är ju en sak men jag kan inte riktigt greppa att det skulle kunna vara istället för multipelt arv (nu är det själva arvet jag hänger upp mig på).

Nån som kan förklara detta?

Beror väl på vad som avses med multipelt. Det man får är ju som du säger en slags överklass som man kan ärva ifrån. Skillnaden mot vanligt arv med extends som man endast kan göra en av, så går det att göra flera implements av flera olika gränssnitt. Således motsvarar det mulitpelt arv. Vidare så är den ju som sagt alltid abstrakt och ska endast definiera ett gränssnitt och ingen körbar kod.

Jo, där är det ju glasklart (att man ärver ett gränssnitt) men jämför man med C++ så ärver man ju där ren kod. Kod som har någon funktion. I ett gränssnitt har man ingen kod alls.

Det är just detta faktum som jag hänger upp mig på när man säger att det inte finns multipelt arv som i C++ men att man har gränssnitt som ett sorts surrogat för detta.

Finns där inget att ärva varför då snacka om att man ärver?!
Att endast vara tvungen att använda vissa givna metodnamn när man implementerar ett gränssnitt tycker jag inte är att ärva i egentlig mening.

Som kanske märks här så har jag väldigt dålig koll på gränssnitt men visst funkar det väl som så här:
-man anger att man ska implementera ett visst gränssnitt.
-i sin klass implementerar man sen alla de funktioner som anges i gränssnittet.

Några förslag på böcker eller hemsidor som ger en utförlig förklaring över gränssnitt?

citte skrev:

Jo, där är det ju glasklart (att man ärver ett gränssnitt) men jämför man med C++ så ärver man ju där ren kod. Kod som har någon funktion. I ett gränssnitt har man ingen kod alls.

Men det är ju det som är ett gränssnitt. Det är likadant i C++ m.h.a nyckelordet "virtual".

Finns där inget att ärva varför då snacka om att man ärver?!
Att endast vara tvungen att använda vissa givna metodnamn när man implementerar ett gränssnitt tycker jag inte är att ärva i egentlig mening.

Nej, så heter det inte extends heller, utan implements.

Ett gränssnitt är en deklaration på vad som ska finnas och med en abstrakt överklass kan man binda ihop olika klasser i en hiearki under, vilket har fördelen att göra livet lite lättare. Ta iterator som exempel. En implementation av den kräver vissa hjälpmetoder och dessa definieras på ett visst sätt. Det är gränssnittet iterator man implementerar för att säkerställa att iterator fungerar och kommer att fungera ihop med andra klasser eftersom ett gränssnitt fungerar som en abstrakt överklass och binder ihop dynamiskt.

Nej, det är inget rent "arv" men å andra sidan är inte ett arv av en virtual klass i c++ heller ett "riktigt" gränssnitt ;)

Böcker? Tja, alla javaböcker med självaktning och som riktar sig mot nybörjare tar upp ämnet.
Website? Söker man på sun kommer följande resultat upp: http://search.java.sun.com/search/java/?qt=interface&Search.x=0&Search.y=0&Search=search

Annars kan nog även google bistå med mera :)

Btw... ämnet har varit uppe tidigare så om du söker här i forumet med sökfunktionen på ordet "interface" hittar du mer information

Ok, tack för hjälpen.

Jag är hyfsat erfaren men har av någon anledning helt snöat in mig på interface. Det har klarnat lite faktiskt.

Tack än en gång.

Menade inte att du inte "kan" Java - vi kan alla snurra till det mest triviala ibland. Så är det bara :)

Hittade en mycket intressant artikel på JavaWorld som handlade om interfaces, och varför superklasser inte bör användas. http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

Bra läsning om man vill förstå sig på interfaces.

Tack så mycket!

Ska läsa den så fort jag får tid.

Problemet med multipelt arv är följande:

Class A har funktionen int kul() som returnerar 7 varje gång.
Class B har funktionen int kul() som returnerar ett slumptal avrundat till närmaste heltal mellan 1-10.

I C++ kan du skriva:

public class Knas : public A, public B {...} /*Terminologin är möjligen fel, har varit ett långt skönt sommarlov precis.*/

Vad händer nu om vi kör kul() i en instans av Knas? :q Bra fråga.
Olika programspråk som tillåter multipelt arv löser detta på olika sätt. I Java uppstår det aldrig någon konflikt eftersom du väljer hur du implementerar metoden i varje klass. Därmed minskar risken att du får ett oväntat beteende därför att du glömt att två metoder råkade ha samma namn i föräldraklasserna.

Jag passade samtidigt på att läsa "Why getter and setter methods are evil", från samma författare. Den hittas på: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?

Inte för att starta ett språkkrig här, men jag tycker att han har en vettig poäng. Att C# ( Vet inte hur det är med resten av .NET ) då har set- och get-block inbyggt, är det då dålig design av språket? Självklart kan man ju själv som programmerare göra något åt det, men det känns ändå lite udda, tycker jag.

Har C# nånsin utgett sig för att vara "pure OO" då?
Som exempel så har ju C++ som bekant "stöd" för OO, men det innebär ju inte att C++ är ett äkta OOP-språk automagiskt och som bekant går det mer en regel än undantag att man frångår något av hörnstenarna i OO när man bygger ett C++ program ;)

Sant. Men det borde ju ändå vara något att sträva efter, för att inte användarna av språken ska "göra fel"? Det är ju inga revolutionerande grejjer det handlar om, bara ett par rader mindre kod. Och för att behålla objektorienteringen skulle åtminstone jag skriva de där extra raderna kod.

Jag håller med dig SPiN :)