Verständisfrage, abstrakte klassen, interfaces

Mojito Mix
DON'T PANIC
Beiträge: 42
Registriert: 10. Okt 2007 18:28

Verständisfrage, abstrakte klassen, interfaces

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 :shock:

Benutzeravatar
blackcomb
Mausschubser
Mausschubser
Beiträge: 70
Registriert: 1. Okt 2007 15:48
Wohnort: Darmstadt

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
BSc Spammer
BSc Spammer
Beiträge: 1263
Registriert: 23. Aug 2007 12:46
Wohnort: DA

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
DON'T PANIC
Beiträge: 42
Registriert: 10. Okt 2007 18:28

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

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

Benutzeravatar
labambaman
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 191
Registriert: 8. Jun 2004 12:32

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.
Gruß Nico

Benutzeravatar
guido
Computerversteher
Computerversteher
Beiträge: 378
Registriert: 30. Nov 2003 21:24
Wohnort: Mühltal
Kontaktdaten:

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

Benutzeravatar
giftnudel
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 112
Registriert: 3. Mai 2005 11:26

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
Nerd
Nerd
Beiträge: 681
Registriert: 26. Okt 2006 14:04
Kontaktdaten:

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."

Benutzeravatar
guido
Computerversteher
Computerversteher
Beiträge: 378
Registriert: 30. Nov 2003 21:24
Wohnort: Mühltal
Kontaktdaten:

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

Benutzeravatar
mantra
Computerversteher
Computerversteher
Beiträge: 385
Registriert: 23. Okt 2005 23:56
Wohnort: Wiesbaden

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.

Benutzeravatar
guido
Computerversteher
Computerversteher
Beiträge: 378
Registriert: 30. Nov 2003 21:24
Wohnort: Mühltal
Kontaktdaten:

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

Antworten

Zurück zu „Archiv“