equals vergleich

[sousou]

Hallo zusammen,



Ich hab grad im Internet mal wieder gelesen das der Vergleich bei Equals im einfachsten Fall vom gleichen Typ ist. Das heisst wenn zwei Objekte den gleichen Typ haben dann ist das true.

Beispiel:

Buch o1 = new Buch();
Buch o2 = new Buch();

if (o1.equals(o2) ) { return true; } else { return false; }

Mich wunder aber folgendes:

class Buch{ 
  public boolean equals(Object other) {
    ...
    if (other.getClass() != getClass())
      return false;
    ...
  }

downcast.....
}

Weshalb das true ist, versteh ich nicht.... Da other.getClass den Namen der Oberklasse mit den Namen der Unterklasse vergleicht. Diese doch unterschiedlich da der Typ der Oberjkasse Object ist und der Typ der unterklasse den Typ hat in der sich equals befindet. Beispielsweise Buch.


Weshalb ist das denn true?

 

[mvitz]

Weil in dem Falle Other nicht vom Typ Object, sondern auch vom Typ Buch ist.

 

[sousou]

wär wirklich sehr nett, wenn sich jemand bei der antwort ein bissien mühe gibt es mir etwas deutlich zu erklären.


DIe einen sagen es ist nicht mehr vom Typ Object die anderen sagen es ist vom Typ Buch.

Also was stimmmt jetzt?

 

[SlaterB]

bisschen rücksichtsvoller formulieren bitte,
wäre auch schön wenn deine Frage klarer wäre


> Weshalb ist das denn true?

worauf beziehst du dich?, auf die Aussage

Ich hab grad im Internet mal wieder gelesen das der Vergleich bei Equals im einfachsten Fall vom gleichen Typ ist. Das heisst wenn zwei Objekte den gleichen Typ haben dann ist das true.

das klingt sehr falsch, wo hast du das gelesen? wahrscheinlich nur falsch verstanden,

oder meinst du
> if (o1.equals(o2) ) { return true; } else { return false; }

da wird in einer unbekannten Methode true zurückgegeben, wenn zwei Objekte gleich sind,
das bedeutet nicht, dass die equals-Methode vom Typ der Objekte abhängt

 

[eRaaaa]

Das zeigt doch wieder, dass du dir das letzte mal den Link den man dir gegeben hat, nicht gelesen hast...

Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 6.9 Typen in Hierarchien

Da steht alles zu dem was dir gerade Probleme bereitet...

 

[sousou]

doch habe ich !! Deine unsinnige vermutung ist nicht notwendig.



und das steht hier:
AngelikaLanger.com - Implementing the equals() Method - Part 1 - Angelika Langer Training/Consulting


Test auf Vergleichbarkeit
Nachdem getestet ist, dass other keine null-Referenz ist, wird auf Vergleichbarkeit geprüft. Interessanterweise ist das das kontroversesten Themen im Zusammenhang mit equals() überhaupt. Wir werden den Test auf Vergleichbarkeit in der nächsten Kolumne noch näher beleuchten. Hier nur ein erster Einblick in die Problematik.

Der Vergleichbarkeitstest ist nötig, weil equals() ein Argument vom Typ "Referenz auf Object" akzeptiert. Eine solche Referenz kann daher auf jede Art von Objekt zeigen und es ist keineswegs sicher gestellt, dass other auf ein Objekt desselben Typs wie this zeigt oder dass die referenzierten Objekte wenigstens in irgendeiner Form vergleichbar sind. Die Vergleichbarkeit muss daher durch einen expliziten Test feststellen.

Das heißt, man muss sich vor der Implementierung von equals(), genau genommen schon beim Design der Klasse, überlegen, mit welcher Art von Objekten ein Vergleich überhaupt möglich und sinnvoll ist. Im einfachsten Fall ist der Vergleich nur zwischen Objekten gleichen Typs erlaubt. Das sieht dann wie folgt aus:

public boolean equals(Object other) {
...
if (other.getClass() != getClass())
return false;
...
}

 

[SlaterB]

boah, du schlägst ja einen Ton an,
zum Glück bin ich noch mehr interessiert als empört,

auf der Seite sind gefühlt 500 Zeilen, die lese ich zumindest nicht durch
bei Suche nach 'Typ' kam ich am ehesten noch auf die Sätze

> Hingegen ist der Vergleich immer dann möglich, wenn this und other von genau dem gleichen Typ sind.

> Im einfachsten Fall ist der Vergleich nur zwischen Objekten gleichen Typs erlaubt

welche aber nicht wirklich 'Das heisst wenn zwei Objekte den gleichen Typ haben dann ist das true.' bedeuten


edit: ah, jetzt hast du etwas mehr geschrieben, da kann ich das aber immer noch nicht rauslesen,
wenn der Typ nicht gleich ist, dann macht ein Vergleich keinen Sinn, dann kann man gleich false zurückgeben, so ist das zu interpretieren,
wenn der Typ gleich ist, dann wirds erst interessant, dann die Felder vergleichen usw.

 

[eRaaaa]

Stimmt, es war eine Vermutung, und zwar vermute ich das, anhand deines folgenden Satzes:

Da other.getClass den Namen der Oberklasse mit den Namen der Unterklasse vergleicht. Diese doch unterschiedlich da der Typ der Oberjkasse Object ist und der Typ der unterklasse den Typ hat in der sich equals befindet

Das stimmt eben nicht und das kannst du so auch nicht sagen, da du nur aus der Methode heraus, doch gar nicht sagen kannst welches Objekt der Methode übergeben wird? Dich verunsichert immernoch das Object in der Signatur ...

	Object obj = new String("Hallo, ich bin ein String!)");
	System.out.println(obj.getClass());

= new .... darauf kommt es an! Auf obj kannst du jetzt zwar keine Methoden mehr aus String aufrufen (dafür müsstest du es halt wieder downcasten) aber es ist immer noch ein String !!!!!! Und genau das steht im Link...

 

[sousou]

Ja danke das is mir jedoch klar, zu den anderen da geht darum das ich nicht mag wenn jemand sachen behauptet was nicht stimmt, was man nicht wissen kann und dann noch einfach so einen unterstellt.

Das geht auch netter.

Die Frage von mir ist eigentlich nur warum obj in der Methode equals vom Typ Buch in der Klasse Buch ist und nicht vom Typ Object obwohl es mit dem Typ Object deklariert ist.


Die einzigste Antwort die ich hierzu bekommen war ist:

Weil in dem Falle Other nicht vom Typ Object, sondern auch vom Typ Buch ist.

Aber die begründung steht nicht da. Und etwas wissen ohne etwas begründet zu bekommen ist kein Wissen. Deswegen die Frage.

Das wärs auch.

 

[sousou]

achsoooooooooooooo era ich hab zu danken.

stimmt ab new weiß man zu welchen Objekt es gehört .

Ich gucks mir nochmal an, vielleicht kommt die in oder andere Frage.

THX!

 

[Gelöschtes Mitglied 5909]

ich empfehle dir folgende Artikel, aus Effective Java

http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf