Interface mit fertiger Methode

[Guest]

Hi,

wie kann ich (bzw ist es überhaupt möglich) durch die implementation eines interface fertige Methoden zu bekommen, d.h. nicht abstact habe es bisher mit interface extends class versucht, leider erfolglos

Fehlermeldung:
The type figur cannot be a superinterface of Ifigur; a superinterface must be an interface

 

[AlArenal]

Hi, wie kann ich (bzw ist es überhaupt möglich) durch die implementation eines interface fertige Methoden zu bekommen, d.h. nicht abstact habe es bisher mit interface extends class versucht, leider erfolglos

public class MeineKlasse implements MeinInterface {

Lass mich raten: Bücher sind dir ein Graus?

 

[Guest]

public class MeineKlasse implements MeinInterface {

Lass mich raten: Bücher sind dir ein Graus? [/quote]

das ging aber fix, vielen dank.

ja manchmal sind mit Bücher wirklich ein graus, aber hier habe ich mich glaub ich nicht ganz korrekt ausgedrückt:

also:
in einem interface kann ich nur abstrakte methoden schreiben,
ich will aber mit meinem interface die methoden schon mit einer funktionalität belegen, und sie nicht erst in meiner klasse die das interface implementiert auschreiben

interface mathe
public int add(int Zahl1, int Zahl2)
{
return Zahl1 + Zahl2;
}

class addieren implements math
{
int summand1 = 6, summand2 = 7, ergebnis = 0;
ergebnis add(summand1 + summand2);
}



das is nur zur verdeutlichung meines problems, keint code

 

[AlArenal]

ja manchmal sind mit Bücher wirklich ein graus, aber hier habe ich mich glaub ich nicht ganz korrekt ausgedrückt:

also:
in einem interface kann ich nur abstrakte methoden schreiben,
ich will aber mit meinem interface die methoden schon mit einer funktionalität belegen, und sie nicht erst in meiner klasse die das interface implementiert auschreiben

Das geht in einem Java-Interface nicht, weil es auch nicht Sinn und Zweck eines solchen ist. Die Implementierung kann nur in einer Klasse (egal ob abstrakt oder konkret) erfolgen.

Daher auch mein Kommentar mit den Büchern, denn das wirst du in einem jeden entsprechenden Buch als Hinweis und Beschreibung finden.

 

[Foermchen82]

Was ist dann aber eigentlich der Sinn eines Interfaces? man kann doch gleich ein Objekt von einer Klasse erzeugen und so auf die funktionalität zugreifen.

 

[Guest]

ich würde aber gern, gibt es keinen trick mit dem ichs machen kann?
daher meine erste überlegung interface extends class
momentan versuche ich in ein interface eine klasse zu schreiben auf deren methoden ich dann mit dem implementieren des interface zugreifen will, :### :### :###

 

[SamHotte]

Was ist dann aber eigentlich der Sinn eines Interfaces? man kann doch gleich ein Objekt von einer Klasse erzeugen und so auf die funktionalität zugreifen.

Ganz einfach. Wenn für ein Interface verschiedene Implementierungen sinnvoll sind, sollte man bei seiner Variablendeklaration das Interface verwenden. Tauscht man später die Implementierung aus, braucht man nicht an tausend Stellen im Programm den Typ zu ändern, sondern nur dort, wo die Objekte erzeugt werden.

Schau dir mal java.util.Map mit den zig Implementierungen an.

 

[AlArenal]

Was ist dann aber eigentlich der Sinn eines Interfaces? man kann doch gleich ein Objekt von einer Klasse erzeugen und so auf die funktionalität zugreifen.

Sinn ist zum einen das Erreichen von Unabhängigkeit gegenüber einer bestimmten Implementierung (Klasse). Programmiere ich beispielsweise gegen java.util.List (ein Interface), ist es egal ob ich da nun konkret eine Instanz der Klasse ArrayList oder Vector nutze. Beide implementieren das Interface, tun dies womöglich aber intern ganz anders. Das kann mir aber egal sein, weil ich davon nichts mitbekomme.

Ein Interface beschreibt eben eine Schnittstelle, mit der ich auf ein Objekt zugreifen kann. Ein solches fasst meist sinnig zusammengehörende Methoden zusammen. Außerdem kann eine Klasse belibig viele Interfaces implementieren, aber nur von einer Basisklasse abgeleitet sein.

ich würde aber gern, gibt es keinen trick mit dem ichs machen kann?

So wenig wie es einen Trick gibt deinen Mercedes SLK mit einer 9 Volt Blockbatterie anzutreiben. Einfach aufgrund dessen, weil es so nicht vorgesehen und demnach auch nicht sinnvoll ist (und es Sinn macht unsinnige Verwendungen nicht zuzulassen).

daher meine erste überlegung interface extends class
momentan versuche ich in ein interface eine klasse zu schreiben auf deren methoden ich dann mit dem implementieren des interface zugreifen will, :### :### :###

Versuch lieber erstmal ne Runde zu lesen. Es bringt dir nichts stundenlang zu versuchen die Sprache zu vergewaltigen (was nicht klappen wird). Lern lieber wie was funktioniert und wozu es gut ist.

 

[Foermchen82]

Das soll also heißen, dass ich für die selbe abstracte interface-methode (z.B. "Ticketkaufen();") gleichzeitig mehrere Implementierungen haben kann (z.b. am automat, online, am schalter)? Wie wird das dann aber unterschieden, welche variation genommen wird???

 

[AlArenal]

Das soll also heißen, dass ich für die selbe abstracte interface-methode (z.B. "Ticketkaufen();") gleichzeitig mehrere Implementierungen haben kann (z.b. am automat, online, am schalter)? Wie wird das dann aber unterschieden, welche variation genommen wird???

Da muss nichts unterschieden werden. Nehmen wir mal ein nachvollziehbares Beispiel:

Denken wir uns ein Interface namens Fahrzeug. Ein Fahrzeug kann ja vieles sein (Flugzeug, Auto, Roller, ...), aber man kann beschleunigen, abbremsen, nach links und rechts steuern, ... Nun kannst du dir beliebig viele Klassen basteln, die das Interface implementieren. Bezogen auf das Interface kannst du diese aber alle gleich behandeln. Es ist egal ob es von einer Klasse Auto oder einer Klasse Hubschrauber implementiert wird.
Intern funktioniert das lenken und beschleunigen natürlich in unterschiedlichen Fahrzeugen auch auf unterschiedliche Art und Weise - das ist uns aber dank des Interface egal. In unserem Programm könnte man mit nem Führerschein für ein Fahrzeug auch tatsächlich jedes Fahrzeug grundlegend steuern. Ich muss nicht wissen auf welchen Schalter ich drücken, welchen Hebel ich bewegen muss.. das weiß die implementierende Klasse und agiert entsprechend, denn darin isses eben umgesetzt.

 

[Guest]

naja so langsam glaub ich das es net geht, aber dann is die mehrfachvererbung fertig implementierter methoden in java nicht möglich, oder?

m1: print "ich geh zurück zu QBasic"
goto m1

 

[SamHotte]

Lesen! Deine Fragen beziehen sich auf die absoluten Grundlagen der Objektorientierung. Die Antworten findest du in jedem Buch.

 

[AlArenal]

naja so langsam glaub ich das es net geht, aber dann is die mehrfachvererbung fertig implementierter methoden in java nicht möglich, oder?

m1: print "ich geh zurück zu QBasic"
goto m1

Nein, weil sie auch nicht wirklich nötig ist. Stell dir zwei Klassen A und B vor, die die Methode bla() haben und nun backst du ne Klasse C, die von A und B erbt. Was soll nun passieren wenn C.bla() aufgerufen wird? Ohne Mehrfachvererbung kann man sich solche Gehirnakrobatik, die man wieder durch irgendwelche Syntax und zusätzliche Konstrukte behandeln muss (was die Sprache wieder komplexer und die Beherrschung schwieriger macht), sparen.

 

[Foermchen82]

Das soll also heißen, dass ich für die selbe abstracte interface-methode (z.B. "Ticketkaufen();") gleichzeitig mehrere Implementierungen haben kann (z.b. am automat, online, am schalter)? Wie wird das dann aber unterschieden, welche variation genommen wird???

Da muss nichts unterschieden werden. Nehmen wir mal ein nachvollziehbares Beispiel:

Denken wir uns ein Interface namens Fahrzeug. Ein Fahrzeug kann ja vieles sein (Flugzeug, Auto, Roller, ...), aber man kann beschleunigen, abbremsen, nach links und rechts steuern, ... Nun kannst du dir beliebig viele Klassen basteln, die das Interface implementieren. Bezogen auf das Interface kannst du diese aber alle gleich behandeln. Es ist egal ob es von einer Klasse Auto oder einer Klasse Hubschrauber implementiert wird.
Intern funktioniert das lenken und beschleunigen natürlich in unterschiedlichen Fahrzeugen auch auf unterschiedliche Art und Weise - das ist uns aber dank des Interface egal. In unserem Programm könnte man mit nem Führerschein für ein Fahrzeug auch tatsächlich jedes Fahrzeug grundlegend steuern. Ich muss nicht wissen auf welchen Schalter ich drücken, welchen Hebel ich bewegen muss.. das weiß die implementierende Klasse und agiert entsprechend, denn darin isses eben umgesetzt.

Das war ja meine Frage: Wenn ich verschiedene Fahrzeuge habe, die alle über das gleiche Interface angesprochen werdne können, wie wird da die implementierende Klasse dann herausgefunden wenn es da etwas für Flugzeug, auto, Roller,... gibt

 

[AlArenal]

Wenn ich verschiedene Fahrzeuge habe, die alle über das gleiche Interface angesprochen werdne können, wie wird da die implementierende Klasse dann herausgefunden wenn es da etwas für Flugzeug, auto, Roller,... gibt

Sag dem Roller er soll beschleunigen und er weiß, dass er beschleunigen soll... Die Frage erinnert mich jetzt fatal an "Woher weiß das Telefonbuch all die Nummern?"....

 

[Foermchen82]

Das Interface ist doch aber nicht Roller sondern Fahrzeug oder nicht??

 

[AlArenal]

Das Interface ist doch aber nicht Roller sondern Fahrzeug oder nicht??

Ja und? Aufgerufen werden die Methoden ja nur bei nem Objekt, also ner Instanz einer konkreten Klasse - anders gehts ja nicht. Und wenn diese Klasse das Interface implementiert, muss ich mir keinen Kopf mehr machen...

public interface Fahrzeug {
  ...

  public void abbremsen(...);

  ...
}

public class Roller implements Fahrzeug {
  ...

  public void abbremsen(...) {
  ...
  }

  ...
}

...

Roller r = new Roller();
r.abbremsen(...);

...

Fahrzeug f = new Roller();
f.abbremsen(...);

...

Object o = new Roller();
((Fahrzeug)o).abbremsen(...);

...

 

[Guest]

also haben ein interface und eine klasse von der logik nichts gemeinsam?
ich habe ein interface fahrzeug in dem ich die abstrakten methoden beschleunigen und bremsen habe
dann habe ich eine klasse roller die bei der methode beschleunigen am gashebel dreht.
dann habe ich eine klasse auto die bei der methode beschleunigen auf das gaspedal tritt.

-> beide methoden machen im kern etwas total verschiedenes, es kommt aber das gleiche ergebniss dabei heraus - sie fahren vorwärts

Richtig bis hierhin?

wenn ich aber methode beschleunigen beim roller wie oben lasse und bei klasse auto methode beschleunigen trete ich auf das bremspedal, dann hat das program ja kein problem damit, trotzdem tue ich vom sinn her das falsche.
ok, bei dem bsp is das ganze schon recht grenzdebil aber bei verzwickteren sachen könnte eine fehlinterpretation der abstrakten methode im interface doch zu logikfehlern führen, oder nicht?

anders ausgedrückt:
wenn ich das ergebnis/den sinn einer abstrakten methode in einem interface kenne, dann weiß ich was die methode nacher fertig implementiert in einer klasse bringt/was für ein ergebnis sie liefert, aber es kann mir egal sein wie gerade die se klasse das tut.

Schlussfolgerung: wenn ich von einer klasse ein objekt erstelle und ich in bei diesem objekt eine methode verwende die aus einem interface stammt und ich diese methode aus dem interface kenne brauch ich nicht in den quellcode der ausgeschriebenen methode zu schauen?

 

[AlArenal]

also haben ein interface und eine klasse von der logik nichts gemeinsam?

Interface und Klasse verhalten sich in etwas wie der Grundriss zu einem Haus.

ich habe ein interface fahrzeug in dem ich die abstrakten methoden beschleunigen und bremsen habe
dann habe ich eine klasse roller die bei der methode beschleunigen am gashebel dreht.
dann habe ich eine klasse auto die bei der methode beschleunigen auf das gaspedal tritt.

-> beide methoden machen im kern etwas total verschiedenes, es kommt aber das gleiche ergebniss dabei heraus - sie fahren vorwärts

Richtig bis hierhin?

So siehts aus.

wenn ich aber methode beschleunigen beim roller wie oben lasse und bei klasse auto methode beschleunigen trete ich auf das bremspedal, dann hat das program ja kein problem damit, trotzdem tue ich vom sinn her das falsche.
ok, bei dem bsp is das ganze schon recht grenzdebil aber bei verzwickteren sachen könnte eine fehlinterpretation der abstrakten methode im interface doch zu logikfehlern führen, oder nicht?

Dafür sollte man seinen Kram ja auch dokumentieren. Wenn ich im Team entwickle und ich schriebe ein Interface und der Kollege soll es mal irgendwo implementieren, muss das Verhalten natürlich definiert sein. Ob die Implementierung richtig ist, kann das Interface nicht prüfen, das kannste später nur durch testen rausfinden. Wenn du ein Haus bauen lässt und sich die Maurer nicht an die Pläne halten, ist das ja auch nicht die Schuld des Architekten und das Stück Papier mit der Zeichnung kann nicht die Bauarbeiter überwachen.

anders ausgedrückt:
wenn ich das ergebnis/den sinn einer abstrakten methode in einem interface kenne, dann weiß ich was die methode nacher fertig implementiert in einer klasse bringt/was für ein ergebnis sie liefert, aber es kann mir egal sein wie gerade die se klasse das tut.

Schlussfolgerung: wenn ich von einer klasse ein objekt erstelle und ich in bei diesem objekt eine methode verwende die aus einem interface stammt und ich diese methode aus dem interface kenne brauch ich nicht in den quellcode der ausgeschriebenen methode zu schauen?

Gesetzt den Fall die API, die du nutzt, ist gut dokumenteiert, kann dir wurscht sein wie der tatsächliche Code aussieht. Ich habe noch von den wenigsten Klassen im JDK den Sourcecode gesehen und das musste ich auch nicht, weil alles ausreichend beschrieben war. Das hat aber nur noch am Rande mit Interface und Implementierung zu tun.

 

[Guest]

vielen dank, für die erläuterungen.
jetz hab ichs endlich begriffen,

meine problemstellung is zwar nicht gelöst aber dafür hab ich mal wieder was gelernt,
apropos in bücher rein schauen:

die syntax und umsetzung hab ich durch das Buch von anfang an verstanden,
der sinn blieb mir aber bis vorhin verborgen

Vielen Dank !!!

 

[Herr der Runden]

so ich hab mich mal regisriert

 

[byte]

meine problemstellung is zwar nicht gelöst aber dafür hab ich mal wieder was gelernt,
apropos in bücher rein schauen

Dein Problem ist insofern gelöst, dass Du weisst, dass es mit Interfaces nicht geht. Die Lösung lautet in Deinem Fall: abstrakte Klasse! Anders geht es nicht, denn Java erlaubt keine Mehrfachvererbung.

 

[Herr der Runden]

Dein Problem ist insofern gelöst, dass Du weisst, dass es mit Interfaces nicht geht. Die Lösung lautet in Deinem Fall: abstrakte Klasse! Anders geht es nicht, denn Java erlaubt keine Mehrfachvererbung.[/quote]

nja eigentlich hatte ich nie ein problem, ich lern immoment halt java und bin im moment halt bei vererbung etc. und da haben mich interfaces interessiert,
aber wieso sollte meine lösung abstrakte klassen heißen?
Fakt is das ich mit java nur von einer klasse fertig implementierte methoden erben kann, ich wollt ja aus mehreren klassen fertige methoden implementieren

 

[Foermchen82]

Also ist es im prinzip möglich, dass man z.b. 3 Klassen hat die alle das gleiche Interface auf unterschioedliche Art und weise implementieren. Aber durch das gleiche Interface könnte man objekte dieser klassen in ein und die selbe Liste packen, oder? Normalerweise geht es ja nicht, weil die Objekte dann unterschiedliche Typen haben.

Seh ich das richtig

 

[AlArenal]

Wenn du eine in Hinsicht auf das Interface typisierte Liste ab Java 5 meinst, ja. Ansonsten ist das List-Interface allgemein auf Object ausgelegt, d.h. man kann jedes Objekt da reinpacken, egal wovon es eine Instanz ist.

 

[Foermchen82]

Ja gut. Aber die Objektlisten in Java mit Objekten verschiedenen Typs zu belegen ist doch nicht sehr sinnvoll. Diese dann wieder richtig auszulesen seh ich als recht schwierig. deswegen meint ich ja, dass hier Interfaces die gemeinsamkeit herstellen um die Objekte gleich behandeln zu können

 

[AlArenal]

Ja gut. Aber die Objektlisten in Java mit Objekten verschiedenen Typs zu belegen ist doch nicht sehr sinnvoll. Diese dann wieder richtig auszulesen seh ich als recht schwierig. deswegen meint ich ja, dass hier Interfaces die gemeinsamkeit herstellen um die Objekte gleich behandeln zu können

Bedies widerspricht sich ja nicht, aber ich weiß was du meinst und da haste auch Recht.

 

[Eldaron]

Ja gut. Aber die Objektlisten in Java mit Objekten verschiedenen Typs zu belegen ist doch nicht sehr sinnvoll. Diese dann wieder richtig auszulesen seh ich als recht schwierig. deswegen meint ich ja, dass hier Interfaces die gemeinsamkeit herstellen um die Objekte gleich behandeln zu können

Genau

Du könntest Dir, um bei dem vorherigen Fahrzeug-Beispiel zu bleiben..
Einen Fuhrpark besorgen, der lauter Objekte, die das Interface "Fahrzeug" implementieren, enthält. Jetzt könntest Du dann (so diese Methode vorgegeben ist) vollTanken() aufrufen für jedes einzelne Element, und die einzelnen Fahzeuge, sei es Roller oder Flugzeug, Solarmobil oder Schiff, führen dann für sich die passende Implementierung aus.

 

[byte]

Fakt is das ich mit java nur von einer klasse fertig implementierte methoden erben kann, ich wollt ja aus mehreren klassen fertige methoden implementieren

Ja. Mehrfachvererbung gibts nicht in Java. Das hat auch einen guten Grund, denn Du bekommst dann Probleme, wenn zwei Klassen teilweise identische Signaturen besitzen (bei unterschiedlicher Implementierung). Daher in Java der Umweg über Interfaces. Sie stellen quasi einen Kompromiss dar, der (in den wenigen Fällen, wo Mehrfachvererbung sinnvoll wäre) einen Mehraufwand bedeutet, aber generell halt die o.g. Probleme verhindert.

 

[Wildcard]

Das gleiche Problem hast du auch mit Interfaces.

 

[AlArenal]

Ja und nein.

Natürlich ist der Fall zweier gleicher Signaturen in zwei zu implenetierenden Interfaces nicht grundsätzlich (explizit) ausgeschlossen.

In der Praxis, wo Interfaces dazu dienen ganz bestimmte sinnverwandte Methoden zusammenzufassen, ist dies aber dadurch impliziert deutlich unwahrscheinlicher.

Nimm nur mal den Fall, dass du von zwei Klassen erben willst, die beide #toString oder #equals, o.ä. überschreiben, was ja nun wirklich keine Seltenheit ist....

 

[Wildcard]

Natürlich ist dieses Problem bei Interfaces bei weitem nicht so häufig wie bei Mehrfachvererbung, aber eben dennoch vorhanden.

 

[byte]

Nein. Das Problem hast Du eben nicht bei Interfaces. Wenn zwei Interfaces teilweise die gleiche Signatur haben, dann haben sie halt eine Schnittmenge. Für die Implementierung spielt das keine Rolle. Die Methode wird trotzdem nur einmal implementiert, ohne dass es zu Konflikten kommt. Es spielt auch keine Rolle, ob das nun die Implementierung der Signatur aus Interface 1 oder 2 ist, wenn beide Signaturen gleich sind.

 

[AlArenal]

Nur ist bei gleicher Sig in unterschiedlichen Interfaces die Möglichkeit da, dass die nicht dasgleiche tun sollen. Aber das ist dann halt der Preis der Freiheit
Suche Run-Time-Fehler, biete Compile-Time-Fehler...

 

[Wildcard]

@Byto:

interface A 
{
     public int foo();
}

interface B
{
     public Bar foo();
}

Und solche Fälle gibt es auch bei reinen Sun-Interfaces....

 

[AlArenal]

Was sind "reine Sun-Interfaces"? Beispiele?

 

[byte]

OK, das ist in der Tat eine Einschränkung, die ich im ersten Moment nicht bedacht hatte. Es zeigt im Grunde, dass weder Mehrfachvererbung noch die Umsetzung der Interfaces in Java der Weisheit letzter Schluß sind.

 

[Wildcard]

Was sind "reine Sun-Interfaces"? Beispiele?

Ist mir vor ein paar monaten passiert. Aber ich geb's ja zu, hab vergessen welche Interfaces das waren, sonst hätte ich sie schon erwähnt.
Tut aber auch nicht wirklich was zur Sache. Kommt sehr selten vor und ist immer irgendwie zu umgehen, also ist es eher ein philosophisches Problem....

 

[AlArenal]

Häufiger isses, dass Klassen gleich heißen und man dann 'fully qualified' arbeiten muss. Ein sehr beliebter Klassenname in dem Zusammenhang ist 'Document'.