Verständnisproblem bei Interfaces

[Saheeda]

Hallo,

mir ist nicht klar, wie und wann ich Interfaces sinnvoll einsetzen sollte/müsste.

Ich weiß, dass Interfaces alle Kindklassen "zwingen", sämtliche Methoden zu implementieren, die auch im Interface stehen.
Ich weiß, dass man damit eine Kapselung erreichen kann, indem man anderen Klassen oder Benutzern gewisermaßen sagt "Von mir kriegst du X, aber wie und woher das kommt, kann dir egal sein."
Ich weiß, dass Klassen nur eine Super-Klasse, aber mehrere "Super-Interfaces" haben können.


Ansonsten ist das Thema für mich ganz dünnes Eis. Wenn in der Aufgabe nicht explizit was von Implementieren steht, käme ich nicht auf die Idee, eines zu basteln.
Auf Teufel komm raus überall Interfaces einbauen, nur um zu zeigen, dass ichs kann, ist mir auch zu doof.


Wie/woher weiß ich also, wann der Gebrauch sinnvoll ist?

 

[Thallius]

Wenn Du es brauchst wirst du es merken, es macht ja keinen Sinn etwas zu benutzen nur weil es das gibt. Viel mehr ist einfach nur gut zu wissen, dass es sowas gibt. Dann kann man es einsetzen wenn man es braucht.

Gruss

Claus

 

[derfreak]

Also ich hatte auch Probleme damit und konnte es mir Anhand eines einfachen Beispiels erklären.
Die Grundlagen weißt du ja jetzt schon, jetzt musst du nur noch wissen wann du es einsetzten "kannst".

Sagen wir mal du hast Waffen, also Gewähre. Was tuhen die alle? Was haben die alle Gemeinsam?
Sie können schießen und man kann sie nachladen.

Sie sehen jedoch alle unterschiedlich aus.

Wenn wir jetzt aber wissen, dass all diese Waffen schießen können, warum bauen wir uns nicht einfach NUR ein INTERFACE wo man schießen kann & ein weiteres wo man nachladen kann.

Wie du sicherlich weißt, kann man nicht mehrmals Erben (extends). Jetzt kommen halt die Interfaces zum Einsatz, du könntest ja von mehreren Interfaces Erben.

Also wenn nun in der Aufgabe steht, Sie haben XYZ dann musst du überlegen, wo die Gemeinsamkeiten liegen, dann KÖNNTEST du ein Interface nehmen.

Falls ich falsch liege, so kann mich ja jemand korrigieren.
Vielen dank

 

[fischefr]

ich darf mal auch ein einfaches Beispiel bringen:

Stell dir vor, du implementierst das Interface Waffe und verschiedene Modelle als Klassen. Außerdem möchte die Bundeswehr (welche bei diesem Beispiel dein Auftraggeber ist) noch, dass du auch ihre Fahrzeuge abbildest.
Und jetzt kommst du in die blöde Situation, dass du gerade an der Klasse "Leopard" (ein Panzer der Bundeswehr) arbeitest. Wenn du jetzt mit Interfaces gearbeitet hast, dann sollte diese Klasse wohl die Interfaces "Waffe" UND "Fahrzeug" implementieren. Hättest du stattdessen mit abstrakten Basisklassen statt Interfaces gearbeitet, hättest du jetzt ein Problem: Java unterstützt keine Mehrfachvererbung. Mit Interfaces kein Problem!

Oftmals wird auch 3stufig gearbeitet:
Interface->Abstrakte Basisklasse->Implementierung
In der Regel leitet man dann von der abs. Klasse ab. Die anderen Klassen, die Objekte dieses Typs dann erwarten verwenden aber den Typ des Interfaces. Das erspart dem Implementierer das Schreiben einiger Methoden (die in der abs. Klasse bereits definiert sein können) verhindert aber an anderer Stelle wieder Probleme mit fehlender Unterstützung für Mehrfachvererbung (weil dann notfalls einfach nur das interface eingebunden werden muss)

 

[Gucky]

Eigentlich sagt die Java Syntax es schon. "extends" bedeutet "erweitert". Also "fügt neue Funktionalitäten hinzu".

Also: Interfaces, wenn Klassen sich eine oder mehrere Methodennamen "teilen" (Stichwort: EventListener).
Vererbung: wenn Klassen wirklich eine Erweiterung der Superklasse sind (bspw. Swing zu AWT).

 

[SilverClaw]

Ich mus sagen, dass ich Interfaces auch eher selten benutze, allerdings sind die wohl auch eher in großen Projekten sinnvoll, wo man vorher im Team die grobe Funktionalität festlegt und dann ert mit Programmieren loslegt.
Ich benutze allerdings gerne "Flag-Interfaces", also solche ohne Funktionen (wobei sich dann früher oder später meist ergibt, dass man die ein oder andere hinzufügt), weil man dann z.B. (ich knüpfe mal an das meiner Vorschreiber an) ein Interface Weapon und ein Interface Vehicle erstellen und belieibg auch verschiedene Klassen verteilen kann.
Wenn man dann z.B. eine Methode für eine Person wie person.giveVehicle(Vehicle v) oder person.giveWeapon(Weapon w) hat, ergibt sich von selbst, dass man einen Golfwagen nur in ersteres, eine Steinschleuder in zweiteres und einen Kampfpanzer, sofern man diesem beide Interfaces gegeben hat, für beides verwenden kann.

Nachtrag: Praktisch ist sowas dann auch für Datenstrukturen, wnen du z.B. einen Fuhrpark als ArrayList haben willst, der Golfwagen, Panzer, Geländewagen, Bobbycars und sämtliche "Vehicle" aufnehmen soll, ohne dass du für das Interface mehr al eine Zeile Code schreiben brauchst. Man spart sich dann grausamere Lösungen wie .isVehicle(), welche ich mit der Zeit dann ansammeln und einen schönen Methoden-Salat ergeben.

 

[Saheeda]

Danke, die Erklärungen und Beispiele haben mir n Stückchen weitergeholfen.
Ich werde die Beispiele mal selbst programmieren, damit ich auch ein besseres Gefühl fürs Handling bekomme.