Sinn von Interfaces

[KaaNo]

Hi Leute!

Ich beschäftige mich mit der Sprache JAVA und beherrsche diese mittlerweile auch sehr gut. Jedoch sind einige Fragen offen geblieben und vorallem die der Interfaces. Könnt ihr mir vielleicht den Sinn und Zweck dieser sagen?

Ein Interface in Java sieht ja so aus, dass ich vor die Klasse einfach interface schreibe und die Methoden in dieser Klasse alle rumpflos sind. Beispiel:

interface Movable
{
  boolean start ();
  void stop ();
  boolean turn (int degrees);
}

So nun zum für mich komischen Teil. Wird einer Klasse nun ein Interface implementiert geschieht das per anhängen von implements Movable (auch mehrere möglich). Beispiel:

class Bike implements Movable
{
  public boolean start () {...}
  // Implementierung von stop und turn sowie weiterer Methoden
  ...
}

Das wäre die ganze Implementierung. Was ich nun irgendwie sinnlos finde ist, dass die Methoden start, stop etc. sowieso in der Klasse mit Rumpf geschrieben werden muss, so dass es eine Funktion bekommt also ist für mich irgendwie das ganze Interface ohne echten Nutzen. Dient das ganze nur der besseren Lesbarkeit des Codes oder warum das ganze? Denn nun werden Objekte ja wie folgt erstellt:

Movable vehicle
...
vehicle = new Bike ();
...
vehicle.turn(20;...

Weiteres Beispiel:

void drive (Movable vehicle, Coordinate from, Coordinate to)
{
  vehicle.start ();
  vehicle.turn (45);
  vehicle.stop ();
}

Danke schonmal für Antworten!

 

[Isaac]

Interfaces sind nützlich wenn du übergeordnete Arbeit deligieren willst. Als gutes Beispiel hat sich hier Collections.sort bewährt.

Stell dir vor du willst etas sortieren, Bauklötze nach ihrer Farbe, Tische nach ihrer Höhe. Personen nach ihrem alter. Mitglieder nach ihrem Eintrittsdatum usw usw.

Der Clou am Interface ist, das es total egal ist nach was du sortieren willst. Wenn du also eine Klasse Bauklotz, Tisch, Person oder Mitglied hast implementierst du das Interface Comparable und kannst dann über Collections.sort deinen Vector of Bauklötze, Tische, Personen oder Mitglieder sortieren und zwar nach den Kriterien die du in den Methoden festgelegt hast, die das Comparable interface vorschreiben.

 

[Sky]

Nicht nur zum Sortieren sind die Interfaces gut. Immer genau dann, wenn mehrere Klassen die gleiche Schnittstelle nach aussen haben müssen, bieten sich Interfaces gerade zu an!

Dein Beispiel hat es doch selbst verdeutlicht:

Jede Klasse, welche dein Interface implementiert hat z.B. die Methoden start() und stop(). Nun ist es völlig egal, ob Du ein Fahrrad, ein Motorrad, ein Auto oder ein Boot hast; durch die allgemeine Schnittstelle kann man von jedem Objekt diese Methoden aufrufen, und das obwohl sie intern wahrscheinlich immer ein wenig anders agieren.

Grüsse Sky

 

[L-ectron-X]

Jaraz hat mal einen schönen Satz hier in diesem Forum geschrieben:

Solange 2 Klassen nicht stark voneinander abhängig sind, sind Interfaces die elegantere Methode Gemeinsamkeiten zu definieren.

Original-Thread: http://www.java-forum.org/de/viewtopic.php?t=4819

 

[AlArenal]

Ich habe z.B. eine visuelle Anwendung, ähnlich ABC/Micrografx Flowcharter oder MS Visio entwickelt und jedes von den grafischen Symbolen ist eine eigene Klasse. Alle definieren aber beispielsweise ein Interface, mit dessen Methoden sich diese Klassen in XML (de-)serialisieren, zwecks Speichern und Laden.

Außerdem, aber soweit bist du vermutlich noch nicht, machts mir erst das möglich vernünftig mittels Reflection auf allen Objekten eines Dokuments zu arbeiten. "Du implementierst Interface XYZ? Aha, dann dann muss ich nun diese Methode von dir aufrufen..." Wenn ich das alles mit if (x instanceof y) machen würde, würde ich ja rattendolle werden...

 

[Bleiglanz]

Ich beschäftige mich mit der Sprache JAVA und beherrsche diese mittlerweile auch sehr gut. Jedoch sind einige Fragen offen geblieben und vorallem die der Interfaces. Könnt ihr mir vielleicht den Sinn und Zweck dieser sagen?

Wer so eine Frage stellt kann nicht von sich behaupten er beherrsche Java "sehr gut"

Was ich nun irgendwie sinnlos finde ist, dass die Methoden start, stop etc. sowieso in der Klasse mit Rumpf geschrieben werden muss, so dass es eine Funktion bekommt also ist für mich irgendwie das ganze Interface ohne echten Nutzen

Denk mal drüber nach! Wenn du innerhalb deines riesigen Projekts eine Methode hast, die so aussieht

public Movable getMover()
{
     // hier irgendwas
     SuperMover mover = new SuperMover()
     return mover;
}

dann können die Clients ganz normal mit Movable programmieren, so als ob das eine Klasse wäre. Wenn aber irgendwann ein SuperDuperMover() auf den Markt kommt, dann kannst du den ganz einfach einbauen OHNE dass die Klassen, die getMover() aufrufen neu übersetzt werden müssen!

oder

in getMover entscheidest du in einem if(), welche Implementierung für Movable du zurückgibst (flexibilität)

oder

du hast ein Array oder eine Collection von verschiedenen Movables: ohne Interfaces müsstest du beim Iterieren jede Instanz in ihren eigenen Typ casten - das wäre ein Alptraum

denk mal über folgenden Tipp nach:

Schreibe immer

List l = new ArrayList();

anstatt

ArrayList l = new ArrayList();

 

[KaaNo]

Aber was wäre so falsch dran, dass genau so zu machen? Im Prinzip ist die ganze Interface Geschichte doch nichts anderes als es der Lesbarkeit dienen zu lassen. Weil so ein krasses Beispiel hab ich bis jetzt noch nicht gesehn, dass mich überzeugt oder einfach ebend den Sinn veranschaulicht. Aber wahrscheinlich bin ich im Moment nur zu blöd das zu kapieren und sollte mir einige komplexere Beispiele anschauen, wenn nicht mal zwei gute Freunde mir das privat erklären konnten.

 

[Sky]

Also, dass ganze hat nichts mit Blöd zu tun. Ich benutze Interfaces in einem konkreten Fall, wo ich Daten nachladen muss. Das Nachladen der Daten geschieht immer auf die gleiche Weise nur, je nachdem, wer (im Sinne von Klasse) die Daten lädt soll automatisch ein nach dem Laden etwas anderes passieren.

Meine Lösung war ein Interface:

public Interface Loadable {
 public void dataLoaded();
}

eine Klasse zum Laden:

public class DatenLaden {
.
.
.
public DatenLaden( Loadable l ) {
   ...
}

public void laden() {
   l.dataLoaded(); // hier findet nun automatisch die Nachbehandlung statt
}
.
.
.
}

und dann Klassen, die das Interface implementiert haben:

...
... new DatenLaden( this );
...laden();
...

So ist sichergestellt dass nach jedem Laden das richtige geschieht, egal, wer wann die Daten nachlädt.

Das Beispiel ist vielleicht noch ein wenig abstrakt, verdeutlicht aber hoffentlich den Sinn!?

 

[Illuvatar]

Am besten verdeutlichen das die Listener aus dem AWT/Swing-Bereich, die auch unter dem Namen "Observer-Pattern" bekannt sind.
http://www.java-forum.org/de/viewtopic.php?t=6090#28148

 

[Isaac]

Btw Graz Illuvatar *g* Nun haben wir gleich 2 Ligen, die 14 und die 15 Jahre Liga *Illuvatar einen binären Kuchen reich*

@Thread
Natürlich kann man alles, was man mit Interfaces macht auch ohne sie machen grac. Aber das schöne ist eben das man sich keine Gedanken mehr machen muss. Wie das sort Beispiel oben zeigt musst du kein Quicksort oder bubblesort mehr selber implementieren. In dem Moment wo du das Interface compareable implementierst und nur die Regeln aufstellst wie sortiert werden soll ist die Sache für den Programmierer schon erledigt da das Sortieren eben die Methode sort übernimmt die sich auf die Interfacemethoden abstüzt.

Wann immer du etwas sortieren willst implementierst du das interface compareable und bist fertig. Also wenn das kein Vorteil ist *g*

 

[Bleiglanz]

Ein anderes Beispiel sind die "leeren APIs" von Sun - z.B. für JNDI, JDBC, Servlets, XML (JAXP) usw.

Von Sun wird da nur ein Haufen Interfaces vorgegeben, die dann von Herstellern ("Providern") implemetiert werden und über einen dynamischen Mechanismus ("Factorys") in eine konkrete Anwendung eingabaut werden

=> nur indem du vollständig gegen Interfaces programmierst kannst du z.B. eine Webanwendung schreiben, die dann ohne Probleme im Tomcat-Server, im Jetty-Server oder in Weblogic laufen kann