Bereits imlplementierte Interfaces nochmal bei "impleme

[Marco13]

Hallo

Eine allgemeine Stilfrage: Wenn eine Klasse von einer anderen Klasse erbt, die ein bestimmtes Interface implementiert, sollte man dann nochmal angeben, dass das interface implementiert wird?

interface Interface {}
class ClassA implements Interface {}

// Und jetzt
class ClassB extends ClassA {}
// oder nochmal 
class ClassB extends ClassA implements Interface {}

Das "implements" dazuzuschreiben wird irgendwie so redundant. Es wegzulassen wirkt irgendwie unvollständig.

Vielleicht will (und sollte!) man an manchen Stellen ja NICHT drauf bauen, dass ClassB die ClassA erweitert, sondern NUR darauf, dass das Interface implementiert wird. (Ob diese Implementierung geerbt wird, oder "direkt" erfolgt, ist ja eigentlich egal). In anderen Fällen will man vielleicht nur, dass von ClassA geerbt wird, und man bekommt das Interface "versehentlich" mit dazu (es gibt je keine Möglichkeit, die Tatsache, dass das Interface implementiert wird, zu "verstecken" - wie etwa bei privater Vererbung in C++). Egal wie man es macht: Bei zukünftigen Änderungen (oder Erweiterungen, oder wenn jemand anderes die Klasse verwenden will) kann sich beides als falsch herausstellen.... ???:L

bye

EDIT: Hm - in das TextField hat der Titel reingepasst :?

 

[Wildcard]

Ich denke nicht das es eine Rolle spielt. IDEs zeigen dir auf Wunsch gerne die gesamte Hierarchie einer Klasse, was wichtiger sein sollte als implements im Klassenkopf.

 

[VuuRWerK]

Ich hab mal gehört das es für eine bessere Lesbarkeit immer von Vorteil ist wenn man alle Interfaces mit angibt auch wenn sie von ElternKlassen implementiert wurden, so gesehen implementiert man sie ja auch, spätestens direkt beim überschreiben.

Ich glaub im OpenBook zu Java6 steht es sogar drin, einfach mal nachlesen.

Gut Schuß
VuuRWerK 😉

 

[Marco13]

Hm. Das einzige, was zumindest in die Richtung geht, wäre das hier
http://www.galileocomputing.de/openbook/javainsel6/javainsel_06_010.htm#t2t36
("Schnittstellenmethoden, die nicht implementiert werden müssen")


Aber meine Frage bezog sich eher darauf, dass man vielleicht eine Konstrukt hat wie

class ClassA implements Comparable {}
class ClassB extends ClassA {}

Jemand, der ClassB benutzt, könnte irgendwann davon ausgehen, dass sie Comparable ist - obwohl man diese Eigenschaft vielleicht nur "versehentlich" von ClassA geerbt hat. (D.h. man könnte dann in Zukunft keine Implementierung von ClassB anbieten, die NICHT mehr Comparable ist).

Umgekehrt hätte man unter Umständen auch ein Problem:

class ClassA implements Comparable {}
class ClassB extends ClassA implements Comprable {}

Wenn man hier NUR von ClassA erbt, um Comparable zu werden, könnte jemand davon ausgehen, dass ClassB immer von ClassA erbt, obwohl man sie durch die Vererbung ja eigentlich nur Comparable machen wollte.

Als einzig "sicherer" Ausweg würde nur bleiben, Interfaces NIE über Vererbung, sondern immer nur in der Klasse selbst (z.B. über ein Delegation-Pattern) zu implementieren. Das wäre wohl die sauberste Lösung, aber kann eben in manchen Fällen recht aufwändig sein...

Naja. Trotzdem danke für die Antworten.

 

[Wildcard]

Um's nochmal zu wiederholen, ich bin sehr begeistert von der Art wie in Eclipse das Extension Object Pattern verwendet wird. IAdaptable implementieren und überall wo ich etwas mit einem mir unbekannten Objekt machen will:

if(o instanceof IAdaptable)
{
     IAdaptable adaptable = (IAdaptable)o;
     Comparable c = (Comparable)o.getAdapter(Comparable.class));
     if(c!=null)
        c.compareTo(anotherObject);
}

 

[maki]

Jemand, der ClassB benutzt, könnte irgendwann davon ausgehen, dass sie Comparable ist - obwohl man diese Eigenschaft vielleicht nur "versehentlich" von ClassA geerbt hat. (D.h. man könnte dann in Zukunft keine Implementierung von ClassB anbieten, die NICHT mehr Comparable ist).

Da der Grund, warum ich davon abraten würde geerbete Interfaces nochmals anzugeben, es täuscht (absichtlich).

Als einzig "sicherer" Ausweg würde nur bleiben, Interfaces NIE über Vererbung, sondern immer nur in der Klasse selbst (z.B. über ein Delegation-Pattern) zu implementieren. Das wäre wohl die sauberste Lösung, aber kann eben in manchen Fällen recht aufwändig sein...

Soweit würde ich nicht gehen, Leute sollten schon die Javadoc lesen (wenn ihre IDE das nicht unterstützt) um zu sehen, zu welchem Objekt die Methode gehört die sie da aufrufen 😉

 

[happy_robot]

ich führe sie (bisher) nur einmal auf.

Ein Interface führt dazu daß ein Objekt allen Referenzen des Interfaces zugewiesen werden kann. Gleiches gilt für die Klassendefinition selber auch. Ableitungen werden und dürfen auch nur einmal angegeben werden. Daher macht es für mich Sinn auch Interfaces nur da anzugeben wo sie auch implementiert werden.

Eventuell würde ich sie nochmal da anführen wenn die ursprüngliche Implementierung überschrieben wird.

 

[Marco13]

Wahrscheinlich ist das mal wieder einer der Fälle wo es keine Silver Bullet gibt. Wenn die abgeleitete Klasse Methoden des interfaces überschreibt sollte man es wohl schon nochmal angeben, aber wenn es eher "zufällig" mitgeerbt wird eher nicht ... muss man wohl von Fall zu Fall entscheiden.

Das mit dem IAdaptable kannte ich nicht, und das ist anscheinend wirklich ziemlich elegant, und kann sicher einige der Probleme lösen, für die man ansonsten solche geerbten interface-implementierungen verwenden würde - das einzige, was mich daran stört, ist die fehlende compile-zeit-Typprüfung ... aber mit einem "<T> T getAdaptable(Class<T> c)" könnte man das vielleicht sogar hinkriegen ???:L boah, bin zu müde, werd' mir das aber auf jeden Fall nochmal ansehen :###

 

[maki]

Wahrscheinlich ist das mal wieder einer der Fälle wo es keine Silver Bullet gibt. Wenn die abgeleitete Klasse Methoden des interfaces überschreibt sollte man es wohl schon nochmal angeben, aber wenn es eher "zufällig" mitgeerbt wird eher nicht ... muss man wohl von Fall zu Fall entscheiden.

Das ist doch immer ein ganz klarer Fall.

Werden Interfaces (nochmals) implementiert, gibt man sie an, ansonsten nicht.

Ansonsten kann ich mich happy_robot nur anschliessen.

 

[Marco13]

So, ausgeschlafen 😎

Sooo klar ist die Sache eben IMHO nicht (sonst hätt' ich ja nicht gefragt :wink: )

"Daher macht es für mich Sinn auch Interfaces nur da anzugeben wo sie auch implementiert werden. "
bzw.
"Werden Interfaces (nochmals) implementiert, gibt man sie an, ansonsten nicht."

Wenn die Implementierung geerbt wird, dann werden sie AUCH implementiert. Und vielleicht ist es ja Absicht und gewollt, GENAU die Implementierung der Superklasse zu verwenden. Dann überschreibt man nichts, und implementiert auch nichts neu, aber will (mit der Erneuten Angebe von "implements") definitiv klarstellen, dass diese Klasse garantiert immer das Interface implementiert - egal, ob sie die Implementierung nun erbt oder selbst macht. Und das interface neu (aber genau so wie in der Superklasse, mit Copy&Paste) zu implementieren, nur um die erneute Angabe von "implements" zu rechtfertigen, macht ja keinen Sinn.

Im Gegensatz dazu: Wenn man das "implements" bei der abgeleiteten Klasse NICHT angibt, und das "implements" bei der Superklasse dann später wegnimmt, hat das auf einmal Auswirkungen auf die abgeleitete Klasse - nämlich, dass man es DORT dann bei "implements" angeben und neu implementieren müßte, weil vielleicht jemand schon darauf aufbaut, dass die abgeleitete Klasse das interface implementiert (obwohl man das ja in der abgeleiteten Klasse nirgendwo explizit zugesichert hat!).

Hm :?

 

[happy_robot]

@Marco13:

kleines missverständnis.

es sollte dir klar sein daß auch mir klar ist daß ein interface wenn es vererbt ist auch in der abgeleiteten klasse implementiert ist.

ich habe eine NEUIMPLEMENTIERUNG gemeint, d.h. wenn die ursprüngliche implementierung des interface überschrieben wird. dann ist eine angabe im rumpf ein indikator dafür daß mit diesem aufgeführten interface etwas in der klasse geschieht.

alle interfaces immer mitzuschleppen ist der transparenz aber nicht wirklich zuträglich.

allerdings sehe ich es jetzt schon so daß es eigentlich egal ist ob man sie angibt oder nicht. wenn man auch noch eine philosophie für angaben von interfaces laufend "pflegen" muss ist es kein gewinn. ausserdem geben eclipse usw genug hilfe um das an ort und stelle herauszufinden (STRG+T).