Sinn von Interfaces - Wozu?

Devil_Noe

Mitglied
Hi!

Trotz aller Beiträge die ich hier und in der Literatur zu diesem Thema gelesen habe, kapiere ich peinlicherweise folgendes immer noch nicht:


Angenommen es gibt die Superklasse "Artikel", aus der sich die Subklassen "Auto" und "Buch" ableiten, die ja unterschiedlichste Eigenschaften haben könnten.

Superklasse Artikel (Die Attribute, die alle gemeinsam haben):

-int Artikelnr
-double Preis

void printArtikelInfo (gibt Artikelnr und Preis aus)

Die Subklassen (zusätzlich spezifische Attribute):

Bsp Auto hat zusätzlich:

double PS
int Türenanzahl

void printArtikelInfo (ruft die super Methode auf und gibt danach noch PS und Türenanzahl aus)

---------------

Das ist mir alles klar, auch das Überschreiben der Methode, je nachdem eben, wer ruft. Was ich aber nicht behirne:

Wenn ich möchte, daß bspw nur die Klasse Auto eine spezielle Funktion beinhalten soll, also zum Beispiel double "berechneMotorbezogeneSteuer", was würde mir da die Implementierung/Verwendung eines Interfaces bringen bzw, warum sollte ich die Methode nicht als "normale" Methode der Subklasse Auto, also genauso wie void "printArtikelInfo" schreiben? Nur, damit eine eventuelle Subklasse von Auto, also z.B. Elektroauto o.ä., diese Methode nicht vererbt bekommt (ginge das nicht auch per Modifier??)? Und: Bei "Buch" würde ich diese ja in diesem Fall gar nicht programmieren.

In beiden Fällen müsste ich den Code innerhalb von Auto schreiben, nur, daß ich im Falle eines Interfaces das Interface benötige (zusätzlich Schreibarbeit, kein Code den ich anderswo verwenden kann, nur Methodenname und values, ..) und nach dem implement gezwungen bin, die Methode auch zu implementieren (oder eben abstract).

Verstehe überhaupt nicht, was der Sinn hinter einem Interface ist.

Kann mir das irgendjemand einfachst erklären?????

:noe:

Thnx for Help!!!!!!!!
 
In deinem Beispiel macht ein Interface tatsächlich keinen Sinn, tatsächlich erkennt man den Sinn von Interfaces auch eher weniger wenn man das Klassensystem von innen betrachtet so wie du, betrachte dein System mal von außen. In den vielen anderen Threads zu dem Thema wurde übrigens schon viele verschiedene Beispiele zu Interfaces gezeigt, darum werde ich jetzt hier nicht noch eins schreiben. Aber versuch mal entweder dein Beispiel von außen statt von innen zu betrachten oder eines der anderen Beispiele nachzuvollziehen, dann kannst du ja immer noch weiter fragen.

Nur, damit eine eventuelle Subklasse von Auto, also z.B. Elektroauto o.ä., diese Methode nicht vererbt bekommt (ginge das nicht auch per Modifier??)?
Interfaces und deren Methoden werden selbstverständlich auch weitervererbt, sonst wären sie ja auch mehr oder weniger witzlos.
 
hmmm, also ich denke, langsam dämmert es .......

sehe ich es richtig, dass ein interface eigentlich nur dann interessant ist, wenn ich bspw. aus einer dritten klasse, die kosten ermitteln soll, kosten von 2 anderen klassen ermittle und dies mittels zb einer funktion int getKosten() mache. wobei das interface sicherstellt, dass die beiden anderen klassen genau diese funktion int getKosten() (= eben eine Funktion die genauso heisst und genau einen int wert zurückgibt) vorhanden haben.

hab ich das nun richtig verstanden??
 
Interfaces sind oft bestimmte "Sichtweisen" auf ein Objekt. Nehmen wir ein Auto. Zwar ist ein Auto immer ein Auto, aber je nach Zusammenhang interessieren uns ganz verschiedene Dinge daran, und das fassen Interfaces zusammen. Für eine Versicherung ist ein Auto ein Versicherungsobjekt, genauso wie ein Haus oder die Mona Lisa. Ein Versicherungsobjekt-Interface würde Besitzer, Alter, Wert usw. beinhalten. Ein Autohändler hätte wiederum ganz andere Prioritäten, und Häuser und Bilder interessieren ihn nicht die Bohne, dafür würde sein Interface vielleicht auch für andere Artikel wie Anhänger und Dachgepäckträger passen.

Was ist nun der Vorteil des Ganzen? Wenn ich einen Automobil-Konzern habe, der auch Versicherungen anbietet, kann ich eine einzige Autoklasse benutzen, die verschiedene Interfaces implementiert: Für den Versicherer sieht ein Auto wie ein Versicherungsobjekt aus, für das Werk wie ein herzustellender Artikel, für den Autohändler wie ein Verkaufsartikel und für die Bank wie ein Vermögenswert u.s.w.
 
Vielleicht mal etwas komplexer:

Stell Dir eine Klasse "Auto" vor.
Die Klasse "Auto" bindet das Interface "salableInterface" (zu deutsch: verkäuflichInterface) ein.
Die Klasse "Dummy" bindet ebenfalls dieses Interface ein - wir könnten jetzt eine Super-Klasse vom Typ "Produkt" erstellen, von der all diese Produkte erben. Aber das lassen wir hier mal außen vor.

Objekte, die das salableInterface einbinden haben eine Methode, mit der sie sich nach Instantiierung in eine Liste X eintragen können.

Nun erstellst Du ein Objekt vom Typ Autohaus, welches von der Superklasse "Store" erbt.
Dieses Autohaus greift sich die Liste der dort eingetragenen Objekte und ruft bei jedem dieser Objekte die von salableInterface vorgeschriebene Methode "addToRangeOfGoods(Store s)" auf.
Dem Autohaus kann egal sein, ob es einen Dummy, eine Tüte Gummiebären oder eine S-Klasse in der Liste X hat, alle diese Objekte beinhalten die Methode addToRangeOfGoods - und nur das zählt.

Ein Interface ist, wie der Name schon sagt, eine Schnittstelle. Man könnte auch sagen, ein Standard auf den man sich einigt.
Dieser Standard eröffnet einem die Möglichkeit zu garantieren, dass Klassen mit teilweise völlig verschiedenen Eltern bestimmte Methoden mit einer ganz bestimmten Aufgabe, weil von einem bestimmten Interface vorgeschrieben, implementieren.
 

Zurück
Oben