Vererbung Problem bei Interfaces

[Maikata]

Hallo,
ich bin grade dabei einige Klassen zu implementieren. Die Interfaces sind gegeben.

Jetzt gibt es eine Methode, die in etwa so aussieht:

public Set<Blub> getAllBlubs();

Blub ist ein Interface, das ebenfalls implementiert wird an anderer Stelle.

Soweit kein Problem, allerdings hab ich folgendes Problem:

Wenn ich jetzt diese Methode implementiere, muss ich die implementation von Blub benutzen, also ändert sich die Methode zu:

public Set<BlubImplementation> getAllBlubs() {
 // viel code hier
}

Das geht aber nicht, da krieg ich ein type missmatch. Wären es keine Sets sondern nur Blub und BlubImplementation wäre es kein Problem.

Was kann ich jetzt dagegen tun?! Hoffe ihr versteht mein Problem.

 

[eRaaaa]

Wenn ich jetzt diese Methode implementiere, muss ich die implementation von Blub benutzen

Wieso das? Das macht ja den ganzen Sinn kaputt! Klar kannst du dann ein Set von Objekten der konkreten Implementierung zurückgeben(was auch sonst?) aber die Methodensignatur kannst du doch so belassen?
Verstehe das Problem jetzt nicht, vllt solltest du deinen Gedankengang erklären

 

[Maikata]

ok ich denke ich habe eher einen verständnis problem.
Also wenn die Interfaces gegeben sind, soll ich diese dann auch für die methodensignaturen verwenden?

Ein weiteres beispiel wäre eben public void setBlub(Blub b);
Sollte ich dann in meiner implementierung das so lassen oder zu setBlub(BlubImplementation b) ändern?

 

[jgh]

die signatur einer Methode, die in einem Interface vorgeschrieben wird...muss genauso auch in der Implentation dieses Interfaces übernommen werden! => "also so lassen" 😉

 

[Maikata]

alles klar, danke 🙂

Noch ne andere kurze Frage.

Wenn jetzt ein Interface ein anderes erweitert und das zweite Interface schon eine Implementierung hat, sollte ich dann eher diese Implementierung als meine super klasse verwenden oder die methoden nochmals implentieren?

public interface Blub extends Lala { }

public BlubImplentation extends LalaImplementation implements Blub {}
oder
public BlubImpementation implements Blub { // und hier dann die ganzen methoden erneut impl.}

Ich denke das zweite is korrekt oder?

 

[nrg]

1, public interface Blub extends Lala { }

2, public BlubImplentation extends LalaImplementation implements Blub {}
oder
3, public BlubImpementation implements Blub { // und hier dann die ganzen methoden erneut impl.}

Ich denke das zweite is korrekt oder?

nehme mal an du meintest bei 2 und 3

public class ...

.
also ich würde sagen, wenn BlubImplentation eine LalaImplementation oder eine signifikante anzahl aus den implementierten methoden übereinstimmen, würde ich 1 nehmen, ansonsten 2. (edit: es reicht dann aber

...extends LalaImplementation {

)

 

[Maikata]

Ja meinte public class. also so siehts aus:

Das ist gegeben und das kann/soll ich nicht verändern:

1, public interface Blub extends Lala { }

1.

public class BlubImplentation extends LalaImplementation implements Blub {}

oder
2.

public class BlubImpementation implements Blub { // und hier dann die ganzen methoden erneut impl.}

Also ist es abhängig vom jeweiligen Projekt... Hmm ok.

Gibts zu dem Thema vielleicht eine gute Lektüre im Internet? (also nicht nur zu interfaces allgemein, sondern wie das in größeren projekten gehandhabt wird mit den interfaces... das prinzip hab ich verstanden, nur nicht wie man sie richtig verwendet...) Weil mir ist glaub ich nicht ganz klar, wofür die interfaces sind. Ich mein, ich könnte das auch alles einfach ohne interfaces machen?!

Ich habe auch ein Klassendiagramm auf dem eben steht, dass Blub von Lala erbt. (was ja auch so ist bei den interfaces). Heißt das jetzt aber auch automatisch, dass BlubImplementation von LalaImplementation erben soll? Und wenn nicht, was bringt mir dann das Klassendiagramm, da sobald ich die Interfaces implementiert habe, es ja nicht mehr ersichtlich ist wer von wem erbt...
Man das macht mciih grad echt fertig :bahnhof:

 

[nrg]

ein grund ist z.b. um von Polymorphie (Programmierung) ? Wikipedia zu provitieren. ich denke das ist recht leicht anhand der library Apache POI zu verstehen. falls du die nicht kennst: Apache POI dient einfach zum arbeiten mit ms office dokumenten. ms hat ja bekanntlich nach v 2003 das dateiformat geändert (2003: xls, 2007+: xlsx).

bei poi deklariert man im grunde alle variablen nur mit den interfaces. d.h. sie können sowohl vom typ 2003 als auch vom typ 2007+ sein. um nun bei einem fertigen code eine 2007er rauszuschreiben, brauchst du im grunde nur die erste instanziierung z.b. des Workbooks zu ändern.

schau dir hier vllt einfach mal paar beispiele an. Busy Developers' Guide to HSSF and XSSF Features. da wirst du recht schnell sehen, dass der unterschied zw. 2003er und 2007er lediglich eine zeile ist.

 

[Marco13]

die signatur einer Methode, die in einem Interface vorgeschrieben wird...muss genauso auch in der Implentation dieses Interfaces übernommen werden! => "also so lassen" 😉

Nein. Seit Java 5 wird kovariante Vererbung unterstützt. Es kann also ein spezifischerer Typ zurückgegeben werden. Das kann seeehr praktisch und sinnvoll sein. Nicht notwendigerweise bei EINEM interface und seiner Implementierung, aber z.B. (!) bei zwei voneinander erbenden Interfaces

interface Lebewesen { }
interface Habitat { Lebewesen getBewohner(); }

interface Mensch extends Lebewesen {}

interface Haus extends Habitat { Mensch getBewohner(); } // Geht, und ist sinnvoll 

Mensch mensch = haus.getBewohner(); // Jedes haus liefert Menschen
Mensch meier = habitat.getBewohner(); // Geht nicht: Habitat liefert nur Lebewesen

(allgemein bei "parallelen Vererbungshierarchien")