[java] Equals functie verifieren

[Boudewijn]

Hoi

Even de cryptische titel uitleggen:

ik ben bezig met een practicum met AspectJ waarbij ik moet bepalen of een equals functie goed is. Hier hebben we 3 checks voor gevonden, als deze alle drie 'okay' zijn, dan is de equals functie ook werkend vinden we.


- Als de class 'equals' overridet, moet de class ook hashCode overriden.
- Hashcode moet bij dezelfde objecten dezelfde hash geven (vrij logisch)
- Zowel equals als hashCode moeten opdezelfde set velden werken. Als velden aan de hand van andere velden worden berekend is het niet nodig deze mee te nemen.

Bron: http://www.javapractices.com/Topic17.cjp


De hashcode-functie kan ik vrij makkelijk controleren door een aantal malen die op het object los te laten, echter vraag ik me af hoe ik nou kan controleren of een klass nou ook echt een functie overridet.

Kan iemand mij mischien een bump in de goede richting geven?
Ik heb de documentatie van AspectJ zo goed en zo kwaad als het gaat (het is vrij droge kost) door proberen te zoeken op dit onderwerp, maar kan het niet vinden.

[.oisyn]

Die derde property is niet helemaal waar. Een hashfunctie zou bijvoorbeeld ook altijd dezelfde waarde terug kunnen geven. De enige eis is dat als geldt a.equals(b), dan a.hashCode()==b.hashCode() (je tweede punt). Of dat zinnig is is natuurlijk een andere vraag - systemen die gebruik maken van de hashcode zullen bij een slechte distributie niet goed performen. Maar het is geen keiharde eis.

Over je vraag, wellicht dat reflection je kan helpen bij het kijken of de method overridden is?

[Confusion]

Dat heeft eigenlijk niets met AspectJ te maken, maar is gewoon algemene Java.

Het is niet verplicht om equals te overriden en als de superklasse aan de voorwaarden voldoet, voldoet een subklasse dat dus ook. Volgens mij probeer je dus iets te doen dat niet nodig is.

[Robtimus]

Stap 1 kun je doen dmv reflection:

Java:

Class<?> c;
try
{
    // in Java 1.4 moet je ook nog een new Class[0] meegeven; lang leve varargs!
    c.getDeclaredMethod("hashCode");
    // hashCode wordt gedefinieerd door de class zelf
}
catch (NoSuchMethodException e)
{
    // niet dus
}

Omdat je alleen naar de declared methods kijkt, en niet c.getMethod(...) gebruikt, weet je dus dat als de exception niet gethrowed wordt dat je class zelf hashCode() definieert.

[Boudewijn]

.oisyn schreef op dinsdag 23 oktober 2007 @ 22:23:
Die derde property is niet helemaal waar. Een hashfunctie zou bijvoorbeeld ook altijd dezelfde waarde terug kunnen geven. De enige eis is dat als geldt a.equals(b), dan a.hashCode()==b.hashCode() (je tweede punt). Of dat zinnig is is natuurlijk een andere vraag - systemen die gebruik maken van de hashcode zullen bij een slechte distributie niet goed performen. Maar het is geen keiharde eis.

Over je vraag, wellicht dat reflection je kan helpen bij het kijken of de method overridden is?

klopt, maar het gaat om aspectj toepassen, niet zozeer om het bewijzen.

Confusion schreef op dinsdag 23 oktober 2007 @ 22:25:
Dat heeft eigenlijk niets met AspectJ te maken, maar is gewoon algemene Java.

Het is niet verplicht om equals te overriden en als de superklasse aan de voorwaarden voldoet, voldoet een subklasse dat dus ook. Volgens mij probeer je dus iets te doen dat niet nodig is.

True, maar ik vermeld de context wel.
Nou ik probeer aan te geven dat als je equals of hash-code overridet, je de andere functie ook moet overriden


@IceManX: ga zo even kijken.