Interface Frage!

[l00P]

Hallo zusammen!

Kann mir jemand erklären worin der Unterschied besteht ob ich in meiner Mainklasse direkt eine instanz einer anderen Klasse erstelle oder das über ein interface tue? Für mich sieht es so aus als wären Interfaces nur eine Last weil ich ja alle Methoden die in einenm Interface stehen auch überschreiben muß?? Also warum da der Weg über das Interface???

Offensichtlich fehlt mir da ein kleines Detail zum Verständnis

 

[André Uhres]

Ein Interface ist ein Sprachmittel für den Entwurf.
Auf diese Weise kann man einen Datentyp schon vor der Implementierung festlegen und benutzen.
Er bleibt aber auch nach der Implementierung immer noch gültig und kann weiter verwendet werden.
Auf diese Weise bleibt die Schnittstelle stets unabhäging von der Implementierung,
von der es auch mehrere Varianten geben kann.

Eine Schnittstelle kann ausserdem von jeder beliebigen Klasse implementiert werden,
ohne daß die Schnittstelle in den Klassenbaum eigeordnet werden muss.
Das ist ein wichtiger Unterschied zu abstrakten Basisklassen.

 

[dieta]

Wenn du eine Klasse hast (z.B. für einen Button), die eine oder mehrere Methode(n) aus einer dir unbekannten Klasse aufrufen soll, macht man das über interfaces: Du übergibst der Klasse, die die Methoden aufrufen soll, ein interface, dass diese Methoden enthält.

Ist jetzt vielleicht nicht so toll erklärt...
Mit Interfaces kannst du Methodenzeiger ersetzen.

 

[l00P]

aha und warum sollte ich von dieser dritten unbekannten Klasse nicht direkt eine Instanz erstellen und dessen Methode verwenden sondern eine Interface Methode überschreiben?? Das ist mir noch unklar?!?

 

[André Uhres]

Damit dein Code unabhängig von der Implementierung bleibt.
Wenn du z.B. das Interface List gebrauchst, dann kann das ArrayList sein oder LinkedList oder sonst was.
Für deinen Code bleibt es stets eine List und du kannst später die Implementierung wechseln ohne deinen Code anpassen zu müssen.

 

[Wildcard]

Ein weiterer Vorteil von Interfaces ist das es eine Pseudo-Mehrfachvererbung ohne deren Nachteile ermöglicht.
Ein Beispiel das in der Regel sofort einleuchtet ist das Comparable Interface.
Listen und Arrays können in Java automatisch sortiert werden solange alle darin enthaltenen Objekte das Comparable Interface implementieren.
Die Autoren der Java-API können deine Klassen nicht kennen.
Da man aber trotzdem einen Mechanismus zu Sortierung beliebiger Objekte anbieten möchte werden Interfaces verwendet.
Eine Klasse die also ein oder mehrere Interfaces Implementiert ist sowohl vom Typ FooBar, als auch vom Typ Interface1, Interface2,...

 

[l00P]

das leuchtet mir ein aber warum kann ich nicht gleich in meinem programm sowas schreiben:

Compareable comp = new Compareable();
comp.sort();

Kommt doch aufs gleiche oder??

 

[AlArenal]

das leuchtet mir ein aber warum kann ich nicht gleich in meinem programm sowas schreiben:

Compareable comp = new Compareable();
comp.sort();

Kommt doch aufs gleiche oder??

Nein. Wenn du dir ne Klasse Leute schreibst und hast x Instanzen rumlungern, die du der Körpergröße nach sorteiren willst, wie kommst du dann an Comparable#sort wenn es keine Interfaces gibt?

Klar, du kannst "class Leute extends Comparable" machen, aber was wenn du auch noch eine Klasse "Fahrzeuge" hast und für ein Spiel willst du dass sich Fahrzeuge und Leute bewegen lassen? Dann wäre es doch ganz hübsch wenn Leute und Fahrzeuge eine Methode wie z.B. #move(int x, int y) hätten. Wenn du beide Klassen diese über ein Interface "Moveable" implementieren lässt, ist dir später egal was du da bewegst, so lange es ein Moveable ist.

 

[l00P]

Ah ich verstehe, in diesem Beispiel bräuchte ich also eine Superklasse von Leute und Fahrzeuge (Was ja schonmal keinen Sinn macht) und in dieser müßte ich dann move() implementieren. Interfaces ersetzen sozusagen die Mehrfachvererbung stimmt das so???

Denke jetzt hab ichs, hab nur zu minimalistisch gedacht

danke

 

[SlaterB]

> Ein Interface ist ein Sprachmittel für den Entwurf.
> Auf diese Weise kann man einen Datentyp schon vor der Implementierung festlegen und benutzen.
> Er bleibt aber auch nach der Implementierung immer noch gültg und kann weiter verwendet werden.

was spricht gegen eine Klasse mit leeren Operationen? (die kann man auch wirklich 'benutzen', ein Interface nicht instanziieren)
diese "Festlegung" kann doch genausogut in der Klasse statt im Interface beschrieben werden

ich sehe den Vorteil fast nur in der Mehrfachbenutzung
(ein Interface, mehrere unterschiedliche Implementierungen)
+ Mehrfachvererbung


in einem Spezialfall machts auch für nur eine Klasse Sinn:
lokales Interface für eine Klasse, deren package man nicht kennt/ nicht importieren will,
weil das z.B. weitere jars erfordern würde/ Probleme bei den Abhängigkeiten beim Kompilieren zwischen mehreren Projekten gäbe

und dann Stubs & Co.

 

[Wildcard]

was spricht gegen eine Klasse mit leeren Operationen? (die kann man auch wirklich 'benutzen', ein Interface nicht instanziieren)
diese "Festlegung" kann doch genausogut in der Klasse statt im Interface beschrieben werden

Ganz einfach:
Damit legst du eine Vererbungshierachie fest

 

[SlaterB]

was ist daran schlecht bzw. anders wenn man später eh diese Klasse verwendet?

 

[AlArenal]

was ist daran schlecht bzw. anders wenn man später eh diese Klasse verwendet?

Weil du nicht alles sinnvoll über eine Hierarchie abdecken kannst, oder willst du jede Klasse von einem Superobjekt, das alles kann, ableiten?

 

[Wildcard]

Du schränkst dich unnötig ein.
Ein Interface lässt einfach die Frage der Implementierung offen, Vererbung gibt die Richtung vor.
Wenn du Schnittstellen zu anderen Objekten festlegst (und damit meine ich nicht zwangsläufig ein Interface), dann willst du eine bestimmte Aufgabe erfüllt haben.
Warum zwingst du denjenigen der das später implementieren soll in eine Vererbungshierachie ohne davon einen Vorteil zu haben?
Vielleicht hat er schon genau die richtige Lösung in der Schublade die allerdings einer eigenen Vererbungshierarchie folgt.

 

[SlaterB]

noch mal von vorne, was ist die Vererbungshierarchie?
wer wird wann warum wie eingeschränkt?

Vererbung wird in einer leeren Klasse doch gar nicht benötigt (ist praktisch ein Interface)
das einzig festgelegte ist der Klassenname anstelle des Interface-Names

 

[AlArenal]

Was für eine leere Klasse? Ich weiß nicht was du so programmierst, aber leere Klasse kann ich nicht gebrauchen

 

[SlaterB]

ich meinte ja, dass man zum 'schnellen Anlegen der Schnittstelle bevor die Implementierung später kommt'
nicht das Java-Sprachmitttel Interface braucht,
statt

interface X {
  operation y();
}

// später kommt class Z implements X

geht auch direkt

class Z {
  operation y() {
  }
}

eine leere Klasse ist genauso schnell geschrieben wie das Interface,

wenn man das Interface nicht für 'richtige' Zwecke wie Mehrfachbenutzung braucht,
dann macht es als 'Sprachmittel für den Entwurf' meiner Meinung nach keinen Sinn,

vielleicht abstrakt gesprochen ein erster Programmierschritt,
aber das kann man mit einer leeren Klasse umsetzen, nicht mit einem Interface

 

[Wildcard]

Du meinst also ein Klassen-Stub nicht als Schnittstelle zwischen Modulen, sondern als kompilierbares TODO?

 

[AlArenal]

Und wenn dann ein Honk doch was reinschreibt und damit eine Implementierung vornimmt? Und wie soll man bei der Definition einer Klasse durchblicken, die dann scheinbar mehrere Klassen erweitert, man aber nicht direkt erkennen kann, welche davon leer sind und welche nicht?

 

[SlaterB]

und wenn man ein Interface hat und ein Honk die Implementierung dazu halb schreibt?
das Argument verstehe ich nicht

eine Klasse ist eh immer in Bearbeitung oder per CVS oder so geschützt,
ist das jetzt auch noch ne Aufgabe von Interface?

> man aber nicht direkt erkennen kann, welche davon leer sind und welche nicht?

man wird doch mal da reinschauen können/ einen Zuständigen haben usw.,
wenn eine Klasse mehrere Interfaces implementiert und für das erste Interface der Code geschrieben wird,
hat man dann nicht das gleiche Problem?

-----

> Du meinst also ein Klassen-Stub nicht als Schnittstelle zwischen Modulen, sondern als kompilierbares TODO?

dieses Technik-BlahBlah.., keine Ahnung

edit: ok, macht Sinn, ja das meine ich

 

[Leroy42]

Was ich an dieser Diskussion bisher vermisse,
ist das Argument: Information Hiding.

Eine Klasse die Objekte verwaltet die irgendetwas
bestimmtes können(eine Methode bereitstellen),
muß und sollte über diese Objekte nur so viel wissen,
wie es sie angeht.

Eine Klasse die z.B. Objekte verwaltet die vergrößert
werden können, geht es überhaupt nichts an und braucht
auch nicht zu wissen ob es sich bei den Objekten um Fahrzeuge,
Landkarten, tibetanische Mönche oder was auch immer handelt.
Für sie ist einzig und allein wichtig, daß sie die Objekte veranlassen
kann, sich zu vergrößern.

interface Vergrößerbar {
  public void setInitialSize();
  public void zoom(int percent);
}

Aus Sicht dieser Klasse sind alle von ihr verwalteten
Objekte eben nur vom Typ Vergrößerbar und
es können auch nur die beiden Methoden auf sie
angewandt werden.

 

[AlArenal]

Ich glaube Slater redet allein vom Vorgang der Programmierung durch den Programmierer. Wir reden Stilmitteln der Software-Architektur. So ganz verstehe ich aber ehrlich gesagt noch nicht wo genau sein Problem liegt...

 

[SlaterB]

jo, mich störte
> Ein Interface ist ein Sprachmittel für den Entwurf.
> Auf diese Weise kann man einen Datentyp schon vor der Implementierung festlegen und benutzen.
wie anfangs ja von mir schon geschrieben

nur für ein "leeres etwas" sehe ich keinen Grund für ein Interface

 

[AlArenal]

Ein Interface ist aber nicht nur ein "leeres Etwas". Es ist die Vorlage einer Struktur, die beliebig von Klassen verwendet werden kann um die dadurch ausgedrückte Funktionlität zu implementieren.

Wenn du in ein Restaurant gehst ist dir auch klar, dass du auf immer dieselbe Art und Weise diene Bestellung abgeben kannst, egal ob Fritten-Ranch oder Sterne-Tempel. Ob der Koch das Gammelfleisch in der Mikrowelle auftaut, oder dem Schwein noch flott selbst die Kehle durchschneidet, kann dir dafür völlig egal sein. Das Interface sagt gibt vor, dass du nach Bestellung des Gerichts dein Essen bekommst. That's it.

 

[SlaterB]

tralala, ich habe doch darauf hingewiesen, wie sehr ich Interface für ANDERE Dinge wie Mehrfachbenutzung schätze,
ich diskutiere nur darüber, dies für genau EINE Klasse zu verwenden,

also ein Interface Fritten-Ranch aus dem nachher eine Klasse Fritten-Ranch wird (braucht sogar noch einen zweiten Namen)
das erscheint mir sinnlos, da reicht auch eine leere Klasse damit 'schonmal was da ist'

 

[AlArenal]

Aber wenn du weißt, dass noch die 5-Sterne-Fresstempel- und die Dönermann-Klasse kommt...

So lange das nicht abzusehen brauchen wir nicht diskutieren, denn so lange isses wirklich witzlos. Da kann man später noch immer refactoren (sp?).