Bereits imlplementierte Interfaces nochmal bei "impleme

Status
Nicht offen für weitere Antworten.

Marco13

Top Contributor
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?

Code:
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

Top Contributor
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

Aktives Mitglied
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

Top Contributor
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
Code:
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:
Code:
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

Top Contributor
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:
Code:
if(o instanceof IAdaptable)
{
     IAdaptable adaptable = (IAdaptable)o;
     Comparable c = (Comparable)o.getAdapter(Comparable.class));
     if(c!=null)
        c.compareTo(anotherObject);
}
 
M

maki

Gast
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

Bekanntes Mitglied
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

Top Contributor
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 :###
 
M

maki

Gast
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

Top Contributor
So, ausgeschlafen :cool:

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

Bekanntes Mitglied
@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).
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
M Java Überprüfen ob .exe-Datei bereits ausgeführt wird Allgemeine Java-Themen 2
KeTho1712 Java Swing: JTable standardmäßig füllen, sodass bei Start bereits Datensätze gespeichert sind Allgemeine Java-Themen 1
Joker4632 Methoden Befehl an bereits extern geöffnete Programm-spezifische Konsole senden Allgemeine Java-Themen 1
O Gucken, ob bereits Töne (von wild fremden Programmen) ausgegeben werden Allgemeine Java-Themen 5
B bereits gelesene Bytes herausfinden Allgemeine Java-Themen 10
R Fehler: Bibliothek bereits geladen Allgemeine Java-Themen 3
J Systemtray bereits vorhanden ja oder nein? Allgemeine Java-Themen 4
M Verwendung von unchecked exceptions & bereits vorhandenen exceptions was priorisieren Allgemeine Java-Themen 3
J String Constanten bereits zur CompileZeit aufloesen? Allgemeine Java-Themen 8
flashfactor Prüfen ob bereits eine Instanz gestartet ist Allgemeine Java-Themen 2
G überpüfen ob bereits instanz von java applikation läuft Allgemeine Java-Themen 4
M Suche , bereits während der eingabe ?? Allgemeine Java-Themen 4
R Lesen von Interfaces (Programm Vervollständigen) Allgemeine Java-Themen 10
S Interfaces Allgemeine Java-Themen 10
S Wenn eine Klasse zwei Interfaces mit derselben Methodensignatur implementiert: welche wird aufgerufen? Allgemeine Java-Themen 15
S Kann man Variablen oder Felder definieren deren Typ zwei Interfaces ist..? Allgemeine Java-Themen 9
J Problem beim Generischen Klassen und Interfaces Allgemeine Java-Themen 2
S Kann ich eine Methode schreiben die alle Arten von funktionalen Interfaces akzeptiert..? Allgemeine Java-Themen 21
Stonie Prüfen von direkter Implementierung eines Interfaces Allgemeine Java-Themen 7
rentasad Design-Frage - Interfaces, Klassen, statische Methoden Allgemeine Java-Themen 3
J Generische Interfaces mehrfach einbinden Allgemeine Java-Themen 11
P Interfaces Allgemeine Java-Themen 1
K Wohin mit Interfaces? Allgemeine Java-Themen 2
J Interface Wofür Interfaces in Java verwenden? Allgemeine Java-Themen 3
F Namen des Interfaces ausgeben Allgemeine Java-Themen 1
P ClassCastException bei Verwendung eines Interfaces Allgemeine Java-Themen 7
F Sinn des Serializable Interfaces Allgemeine Java-Themen 8
G Interface Laden der Konfiguration über Interfaces sinnvoll? Allgemeine Java-Themen 28
X Generic muss zwei Klassen/Interfaces erfüllen Allgemeine Java-Themen 5
K Objekt einer konkreten Implementierung eines Interfaces durch übergebenen String Allgemeine Java-Themen 2
D Java Interfaces Allgemeine Java-Themen 3
sylo toString() Methode eines Interfaces überladen. Allgemeine Java-Themen 17
S statische Interfaces..? Allgemeine Java-Themen 6
M Frage zu Interfaces (Beispiel: Comparable) Allgemeine Java-Themen 13
I Interfaces und abstrakte Methoden Allgemeine Java-Themen 5
C Verständnis zur Strukturierung von Java-Projekten/Interfaces Allgemeine Java-Themen 2
M Methodenaufrufe sind über Interfaces langsamer. Allgemeine Java-Themen 43
J Verständnisfrage zu Casts auf Interfaces Allgemeine Java-Themen 5
J Statische Methoden in Interfaces? Allgemeine Java-Themen 10
J Immutable mit Interfaces möglich? Allgemeine Java-Themen 2
G verzweiflung pur mit java interfaces Allgemeine Java-Themen 5
T Nochmal Frage zu Vererbung Interfaces etc. Allgemeine Java-Themen 10
F Implementierte Interfaces ermitteln Allgemeine Java-Themen 6
T JDBC: Unterschiede in Interfaces zwischen 2 Java-Versionen. Allgemeine Java-Themen 6
E Attribute in Interfaces möglich? Allgemeine Java-Themen 17
I Denkfehler bei Interfaces und Casts? Allgemeine Java-Themen 12
M 2 Java-Interfaces öffnen in Unix Allgemeine Java-Themen 4
B "Instantiieren" eines Objekts eines Interfaces Allgemeine Java-Themen 10
F Problem: mehrere Interfaces definieren equals() neu Allgemeine Java-Themen 24
F Probleme mit Interfaces Allgemeine Java-Themen 3
L Verschiedene Versionen eines Interfaces Allgemeine Java-Themen 12
S Methoden aus Interfaces mit unterschiedlichen Parametertypen Allgemeine Java-Themen 7
deetee Wie nennt man Interfaces wie Serializable? Allgemeine Java-Themen 8
B Elegantere Lösung bei der Implementierung eines Interfaces Allgemeine Java-Themen 2
N 2 Interfaces mit Methoden selber Signatur implementieren Allgemeine Java-Themen 5
D Implementierungen eines Interfaces finden Allgemeine Java-Themen 9

Ähnliche Java Themen

Neue Themen


Oben