Verständisfrage, abstrakte klassen, interfaces

Mojito Mix · Beitrag von **Mojito Mix** » 15. Dez 2007 19:04

Hallo,

worin liegt der genaue Vorteil von abstrakten Klassen und Interfaces?
Wenn ich ein Interface implementiere...muss ich ja nach wie vor die im interface deklarierten methoden in der klasse erstellen. das interface zwingt mich ja quasi nur, dass bestimmte methoden, in einer klasse vorhanden sein müssen...

als großer vorteil wird ja die Mehrfachvererbung von interfaces angesprochen...aber steig noch net ganz dahinter, warum ich ein interface benutzen soll...
aber ich kann doch auch einfach so die methoden in einer klasse implementieren...
das ganze verwirrt mich ein wenig

blackcomb · Beitrag von **blackcomb** » 15. Dez 2007 19:17

Abstrakte Methoden in einer abstrakten Klasse bzw. einem Interface kann man gewissermaßen als "Vertrag" ansehen, den alle Klassen, die von dieser Klasse erben (bzw. dieses Interface implementieren), erfüllen müssen.

Der Vorteil wird vielleicht an folgendem Beispiel deutlich:
Wenn du eine Klasse GeometrischeFigur hast, die eine abstrakte Methode zeichnen() vorschreibt, und des Weiteren verschiedene Klassen, die von der Klasse GeometrischeFigur erben (z.B. Rechteck, Dreieck, Ellipse), kannst du eine Liste von GeometrischeFigur-Objekten anlegen und auf jedem dieser Objekte zeichnen() aufrufen - jedes Objekt wird nun auf seine spezielle Weise gezeichnet, ohne dass du dich darum kümmern musst, ob es jetzt Rechteck, Dreieck oder Ellipse ist. Das Ganze lässt sich dann auch leicht um weitere Figurtypen erweitern, ohne dass bestehender Code geändert werden muss.

Osterlaus · Beitrag von **Osterlaus** » 15. Dez 2007 19:18

Klar kannst du das alles auch manuell machen. Aber stell dir vor, du hast ein größeres Projekt vor. Mehrere Leute hampeln daran herum, beispielsweise eine Klasse zu schreiben, die auf verschiedene Datenbanktypen zugreift. Eine Klasse ist für Typ A zuständig, eine für Typ B, eine für Typ C. Die Gesamtheit der Datenbankklassen soll aber, unabhängig davon, welche Datenbank du nun nutzt, nach außen hin gleich bedienbar sein. Dafür machst du dir zunächst ein Interface, das nun alle Methoden enthält, die von den einzelnen Datenbank-Spezialisten zu implementieren sind. Fügst du nun da eine weitere Methode hinzu, wird jeder Spezialist beim Kompilieren seiner eigenen Klasse merken, dass er noch eine Funktion vergessen hat. So wird auch jede Funktion in jeder Subklasse implementiert.

Zweiter Vorteil: Schon im Interface legst du fest, welche Variablen an die Methode übergeben werden und welchen Typ eine mögliche Rückgabe haben soll. So kannst du wiederum zig Subklassen schreiben, die alle ihre Aufgaben auf eine bestimmte Weise erledigen, aber nach außen hin immer transparent aufrufbar sind. Am Beispiel heißt das wiederum: Ob du nun die Datenbankklasse A nach der Zahl der verfügbaren Tabellen fragst oder Klasse B fragst, du bekommst in jedem Fall einen Integer zurück, so wie es das Interface verlangt.

Mojito Mix · Beitrag von **Mojito Mix** » 15. Dez 2007 19:35

und wann sollte ich lieber eine abstrakte klassen benutzen anstatt eines interfaces?

labambaman · Beitrag von **labambaman** » 15. Dez 2007 19:44

anant_gupta hat geschrieben:und wann sollte ich lieber eine abstrakte klassen benutzen anstatt eines interfaces?

Puh, lange kein Java mehr gemacht. Aber ich meine es war doch so, dass man in Interfaces KEINE Methoden implementieren kann - im Gegensatz zu abstrakten Klassen, die teilweise Methoden implentieren und teilweise halt nur definieren (ohne Implementierung).

Willst du also eine Schnittstelle schaffen (wäre eigentlich ein Interface), hast aber da schon Methoden, die immer genau gleich sein sollen, dann definierst du diese halt in einer abstrakten Klasse (anstatt nur ein reines Interface zu definieren).

Zum Beispiel mit den geometrischen Körpern vielleicht so was wie: getName() und der Name ist eine Membervariable der abstrakten Klasse.

guido · Beitrag von **guido** » 15. Dez 2007 21:06

labambaman hat geschrieben:
Puh, lange kein Java mehr gemacht. Aber ich meine es war doch so, dass man in Interfaces KEINE Methoden implementieren kann - im Gegensatz zu abstrakten Klassen, die teilweise Methoden implentieren und teilweise halt nur definieren (ohne Implementierung).

Korrekt.

Einfache Faustformel: je mehr man für alle Objekte gleich implementieren kann, desto eher sollte man eine abstrakte Klasse nehmen.

Guido

giftnudel · Beitrag von **giftnudel** » 16. Dez 2007 22:22

Man kann doch auch nur von einer Klasse erben, aber mehrere Interfaces implementieren, wenn ich mich korrekt erinnere.

yourmaninamsterdam · Beitrag von **yourmaninamsterdam** » 16. Dez 2007 22:44

giftnudel hat geschrieben:Man kann doch auch nur von einer Klasse erben, aber mehrere Interfaces implementieren, wenn ich mich korrekt erinnere.

Richtig.
Deswegen sollte man auch sinnlose Vererbung vermeiden.

Ein Interface ist im Prinzip nichts anderes als eine 100%ig abstrakte Klasse.

In der Regel ist es so, dass abstrakte Klassen eine Gruppe von konkreten Implementierungen zusammenfassen. Sie tragen dann oft Namen abstrakter Objekte, zum Beispiel "Shape", "Game". Allgemeinsprachlich sagst du dann "Ich hab hier eine (nicht näher definierte) geometrische Figur." oder "Ich hab mir letztens ein Spiel gekauft."
Interfaces definieren eher ein gemeinsames Verhalten. Daher kommen auch Namen wie "Remote", "Serializable", "Comparable" zu Stande. Allgemeinsprachlich hast du also "Dinge, die man vergleichen kann." oder "etwas, das man über Netwerk nutzen kann."

guido · Beitrag von **guido** » 17. Dez 2007 08:20

yourmaninamsterdam hat geschrieben:Ein Interface ist im Prinzip nichts anderes als eine 100%ig abstrakte Klasse.

Jein; auch in einer "100% abstrakten Klasse" könnte man noch gemeinsame Attribute definieren. Und auch bei einer "100% abstrakten" Klasse kann ich nur von dieser - und nicht noch gleichzeitig einer weiteren - Klasse erben. Daher sollte man bei der Aussage oben betonen, "in so Fällen will man aber keine abstrakte Klasse, sondern ein Interface nutzen"

yourmaninamsterdam hat geschrieben:In der Regel ist es so, dass abstrakte Klassen eine Gruppe von konkreten Implementierungen zusammenfassen. Sie tragen dann oft Namen abstrakter Objekte, zum Beispiel "Shape", "Game". Allgemeinsprachlich sagst du dann "Ich hab hier eine (nicht näher definierte) geometrische Figur." oder "Ich hab mir letztens ein Spiel gekauft."
Interfaces definieren eher ein gemeinsames Verhalten. Daher kommen auch Namen wie "Remote", "Serializable", "Comparable" zu Stande. Allgemeinsprachlich hast du also "Dinge, die man vergleichen kann." oder "etwas, das man über Netwerk nutzen kann."

Dem kann ich wieder gut zustimmen

, gerade die Form mit "-able" sind sinnvoll: "alle, die mich implementieren, sind in der Lage X zu tun" ist genau eine sinnvolle Leseweise für Interfaces. Und das übersetzt sich ins Englische eben als "X-able"

, also "Paintable, Drawable, Printable, ..."

Guido

mantra · Beitrag von **mantra** » 17. Dez 2007 11:12

guido hat geschrieben:
yourmaninamsterdam hat geschrieben:In der Regel ist es so, dass abstrakte Klassen eine Gruppe von konkreten Implementierungen zusammenfassen. Sie tragen dann oft Namen abstrakter Objekte, zum Beispiel "Shape", "Game". Allgemeinsprachlich sagst du dann "Ich hab hier eine (nicht näher definierte) geometrische Figur." oder "Ich hab mir letztens ein Spiel gekauft."
Interfaces definieren eher ein gemeinsames Verhalten. Daher kommen auch Namen wie "Remote", "Serializable", "Comparable" zu Stande. Allgemeinsprachlich hast du also "Dinge, die man vergleichen kann." oder "etwas, das man über Netwerk nutzen kann."
Dem kann ich wieder gut zustimmen , gerade die Form mit "-able" sind sinnvoll: "alle, die mich implementieren, sind in der Lage X zu tun" ist genau eine sinnvolle Leseweise für Interfaces. Und das übersetzt sich ins Englische eben als "X-able" , also "Paintable, Drawable, Printable, ..."

Guido

Wenn mans ganz genau nimmt, stimmt auch das nicht

Ein Interface bietet mir die Schnittstelle an. Ob sie das tut, was der Name suggeriert, wird nicht garantiert. Eine Klasse könnte "Comparable" implementieren und so tun, als wäre alles gleich. Die Elemente sind zwar "vergleichbar", aber das wirkliche Verhalten wird nicht definiert. Ich habe dennoch etwas davon, weil ich dann weiß, dass ich "equals" oder "compareTo" aufrufen kann - auch wenn ich nicht unbedingt weiß, was da im Hintergrund geschieht.

guido · Beitrag von **guido** » 17. Dez 2007 11:15

mantra hat geschrieben: Wenn mans ganz genau nimmt, stimmt auch das nicht Ein Interface bietet mir die Schnittstelle an. Ob sie das tut, was der Name suggeriert, wird nicht garantiert. Eine Klasse könnte "Comparable" implementieren und so tun, als wäre alles gleich. Die Elemente sind zwar "vergleichbar", aber das wirkliche Verhalten wird nicht definiert. Ich habe dennoch etwas davon, weil ich dann weiß, dass ich "equals" oder "compareTo" aufrufen kann - auch wenn ich nicht unbedingt weiß, was da im Hintergrund geschieht.

OK; wie groß dann allerdings der Nutzen dieser Implementierung ist (sie entspricht nicht den intuitiven Erwartungen und damit nicht dem unterstellten "Vertrag"), sei dahingestellt

Guido