Aufrufen überschriebener Methoden

[Monzta]

Klasse B erweitert die Klasse A. Dabei überschreibt Klasse B die public Methode m. Kann dann ein Objekt von B irgendwie die Methode m von A aufrufen?

 

[Beni]

ja, mit super.m.

 

[Guest]

das funktioniert meines erachtens nur innerhalb der Methode m...
Das heißt ich muss in die Methode m der Klasse b das super aufrufen.


Sowas wie folgendes geht nur nicht.

B b = new B();
b.super.m()

 

[Ralf Ueberfuhr]

Nee,

public class B extends A {

  public void m() {
    //...
  }

  public void x() {
    super.m();
  }


}

Hatten wir so ne Frage nicht erst?

 

[Monzta]

Darum gehts nicht^^. Die Methoden sind schon geschrieben.
Und ich habe das Objekt bereits erzeugt. Ich kann sowohl an der Methode in A als auch in der in B nichts mehr ändern. Trotzdem will ich die Methode m aus A bei einem Objekt aus B benutzen.
Folgendes reicht nicht:

B b= new b();
((A)b).m();

Das hochcasten auf A hilft nicht, da normal immer die konkreteste Methode aufgerufen wird. Aber ich hätte halt gern irgendwie die Methode A benutzt.

 

[Ralf Ueberfuhr]

Also da wirst wohl nicht mehr rankommen. Das ist ja Sinn und Zweck von überschriebenen Methoden.

Sind es fremde Klassen? Darf man fragen, welcher spezielle Fall bei dir vorliegt oder sind das Firmengeheimnisse?

 

[Monzta]

Wir fummeln in nem GrundstudiumsProjekt der UNI-Bremen an ner Online-Referenz-Bibliothek. Von daher sind unsere Klassen, um die es geht alle nicht wirklich bekannt.

Andererseits existiert das Problem als Teilaspekt bei Javas Collection<T>.
AbstractCollection implementiert wohl Collection und stellt wohl als Abstrakte Klasse equals zur Verfügung. Die Frage ist, wie man da ran kommt, wenn alle Subinterfaces wie List<T> und Set<T> mit AbstractSet und AbstractList ebenfalls ne Implementation von equals bereitstellen. Und natürlich gibts bei Collection kein Konstruktor, weil das ja auch nen Interface ist.

Also frag ich mich, wie man das equals da benutzen könnte. Nur indem man selber in einer eigenen Klasse Collection integriert?
Ich hatte gehofft, man könnte von einem Set aus irgendwie auf das equals von Collection zugreifen.

 

[Roar]

jetz kappier ich auch nix mehr :autsch: also

AbstractCollection implementiert wohl Collection und stellt wohl als Abstrakte Klasse equals zur Verfügung.

AbstractCollection hat jedenfalls keine equals() implementierung.

Die Frage ist, wie man da ran kommt, wenn alle Subinterfaces wie List<T> und Set<T> mit AbstractSet und AbstractList ebenfalls ne Implementation von equals bereitstellen. Und natürlich gibts bei Collection kein Konstruktor, weil das ja auch nen Interface ist.

:autsch: :autsch: hä?
selbst wenn AbstractCollection eine equals() implementierung bereitstellen würde, warum sollte man auf genau *diese* equals() methode zugreifen wollen und können?
wie masseur81 schon sagte: das is nunmal objektorientierung, und ich seh auch keinen fall, wo man so ne umgehung brauchen könnte ???:L

 

[AlArenal]

Wie du selber festgestellt hast, ist Collection ein Interface. Auf dessen Methode kannst du nicht zufgreifen, weil es keine Implementierung in Collection gibt. Sonst wäre es ja kein Interface.

Ebensowengi kannst du an der Tür eines Hauses klopfen, das dein Architekt gerade erst gezeichnet hat.

Was genau willst du eigentlich erreichen?

 

[Monzta]

hmm, naja, klingt ja auch logisch. Ne Ausnahme der Objektorierntierung für mich wäre aber net gewesen .

 

[bygones]

Ich hatte gehofft, man könnte von einem Set aus irgendwie auf das equals von Collection zugreifen.

äh, was ?
warum sollte man wollen ? jede Klasse hat durch das Vererben der Klasse Objekt eine equals Methode.

sicher dass ihr Sets / Collections vergleichen wollt und nicht deren Inhalte ? also die Objekte die die Collections speichern ?

Collection und AbstractCollection implementieren keine equals. Das AbstractSet implementiert eine equals methode

ehrlich gesagt versteh ich in keiner weise was ihr eigentlich machen wollt

edit: boah leute - um die zeit soviele hier... mannomann - get a life ^^

 

[AlArenal]

edit: boah leute - um die zeit soviele hier... mannomann - get a life ^^

Besorg dir Rückenschmerzen, dann klappts auch mit dem Nicht-Einschlafen

 

[Monzta]

die equals Methode in Set ist meines erachtens sowieso so implementiert, dass sie auf gleichheit ihrere Inhalte prüft. Also es wird getestet ob die Objekte des einen Sets alle Objekete des anderen Sets in beliebiger Reihenfolge enthält.


Achja und equals wird wirklich nicht in AbstractCollection implementiert.... da hatte ich wohl ne falsche Vorstellung... ist wohl doch schon zuspät.

Thx für die Infos, ich geh auch ne runde Schlafen :autsch:

 

[Gast]

hi,

die euqals methode wird von der Klasse Object bereitgestellt, und da jede Klasse von Object erbt, ist equals() auch in jeder erzeugten klasse enthalten. Wenn man super.equals() aufruft, dann wird die eqals() aus Object benutzt, da keine (mir bekannte) Klasse diese Methode Überschreibt. Also wird beim Aufruf von equals() nur ein "==" Vergleich (prüft "nur" die Referenz) durchgeführt.
also:
equals(Object o){
return ((Object)this) == o;
}

gruß

 

[KSG9|sebastian]

hae ?

String a = new String("a");
String b = new String("a");

System.out.println(a == b); // false
System.out.println(a.equals(b)); // true

Aber, welchen Sinn soll es haben auf die equals-Methode der Oberklasse zuzugreifen ? Vor allem wenn die "Oberklasse" ein Interface ist ?

Gruß

 

[jPat]

hi,

eine Oberklasse kann keine Interfaces sein, da die Ober"klasse" eine "Klasse" ist und kein Interface. Ein Interface wird immer implementiert, eine Oberklasse wird immer erweitert durch die Kind Klasse.
Zur methode equals() beim String:
:###
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#equals(java.lang.Object)

wird also überschrieben....

grüße