equals method
Passero
What do they compare? May/Can i overwrite it?
Jon Skeet
> I have some home made classes. They all inherrit the method equals, right?
Yes.
> What do they compare?
The current object with what is passed to it.
> May/Can i overwrite it?
You can override it (not overwrite it). See the documentation for
Object.equals for more details.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
dhek bhun kho
> I have some home made classes. They all inherrit the method equals, right?
> What do they compare? May/Can i overwrite it?
It depends on what kind of data your are modelling.
An excerpt from the javadoc:
<a
href="http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Object.html#equals(java.lang.Object)">
The equals method for class Object implements the most discriminating
possible equivalence relation on objects; that is, for any reference
values x and y, this method returns true if and only if x and y refer to
the same object (x==y has the value true).
Note that it is generally necessary to override the hashCode method
whenever this method is overridden, so as to maintain the general contract
for the hashCode method, which states that equal objects must have equal
hash codes.
</a>
Take for example
<code>
public class Fruit {
private String type;
public Fruit(String type);
}
</code>
You would override the hashCode method to return the same values for the
same type:
<code>
public int hashCode()
{
return type.hashCode();
}
</code>
And the equals method
<code>
public boolean equals(Object object)
{
return (object instanceof Fruit)? ((Fruit)object).type.equals(type):false;
}
</code>
This way you can use the objects in a regular manner:
<code>
Fruit apple1, apple2, pear;
apple1 = new Fruit("apple");
apple2 = new Fruit("apple");
pear = new Fruit("pear");
</code>
Thus this would be true:
apple1.equals(apple2);
But this would not:
apple1.equals(pear);
If you want to check for the identity of an apple, whether they are the
same object in the VM you would check for:
apple1==apple2 (false)
apple1==pear (false)
So you have a way to determine whether two objects are logically
interchangeable, beside the fact whether you are working with a
<b>specific</b> object.
Greets.
Bhun.
Passero
"Jon Skeet" <sk...@pobox.com> schreef in bericht
news:MPG.1978a5928...@dnews.peramon.com...
> > What do they compare?
>
> The current object with what is passed to it.
>
Is it the reference that is compared? And if the 2 objects point to the same
object, it gives true?
Jon Skeet
> > > What do they compare?
> >
> > The current object with what is passed to it.
>
> Is it the reference that is compared? And if the 2 objects point to
> the same object, it gives true?
The default Object.equals just compares the references. If you override
it, you can make it do whatever you want - although you should stick to
the semantics described in Object.equals if you want it to behave
reasonably.
VisionSet
"dhek bhun kho" <bh...@to.kenderland.and.back.org> wrote in message
news:pan.2003.07.11....@to.kenderland.and.back.org...
> "Passero" <yano...@pandora.be>, Fri, 11 Jul 2003 09:52:48 +0000:
Boolean bruised;
> public int hashCode()
> {
return type.hashCode() & bruised.hashCode();
> }
And this would be the right thing to do if other attributes you wish to
include in equals?
--
Mike W
Jon Skeet
> Boolean bruised;
>
> > public int hashCode()
> > {
> return type.hashCode() & bruised.hashCode();
> > }
>
> And this would be the right thing to do if other attributes you wish to
> include in equals?
& isn't terribly good, as you end up getting to 0 pretty quickly if you
have several fields. ^ (XOR) is a reasonably good alternative. Josh
Bloch suggests doing something like:
int result = 17;
result = 37*result + type.hashCode();
result = 37*result + bruised.hashCode();
result = 37*result + nextField.hashCode();
etc (being careful to use 0 or something similar for null references,
and applying the step to each element of an array, etc).
Apparently that works pretty well - for one thing, it means the order
of the field comparison matters, which it wouldn't with ^ or &, so if
you have a class with two string fields, the hashcode is different for
"a", "b" than for "b", "a" (almost certainly, anyway).
Thomas G. Marshall
Jon Skeet <sk...@pobox.com> horrified us with:
> VisionSet <sp...@ntlworld.com> wrote:
>> Boolean bruised;
>>
>>> public int hashCode()
>>> {
>> return type.hashCode() & bruised.hashCode();
>>> }
>>
>> And this would be the right thing to do if other attributes you wish
>> to include in equals?
>
> & isn't terribly good, as you end up getting to 0 pretty quickly if
> you have several fields. ^ (XOR) is a reasonably good alternative.
> Josh Bloch suggests doing something like:
>
> int result = 17;
> result = 37*result + type.hashCode();
> result = 37*result + bruised.hashCode();
> result = 37*result + nextField.hashCode();
>
> etc (being careful to use 0 or something similar for null references,
> and applying the step to each element of an array, etc).
>
> Apparently that works pretty well - for one thing, it means the order
> of the field comparison matters, which it wouldn't with ^ or &, so if
> you have a class with two string fields, the hashcode is different for
> "a", "b" than for "b", "a" (almost certainly, anyway).
Jon, what happens if the contract for HashCodes (equal objects have equal
hashcodes) is broken? Do the hashing facilities catch this and use
superclass hashcodes when this occurs?
Jon Skeet
> Jon, what happens if the contract for HashCodes (equal objects have equal
> hashcodes) is broken? Do the hashing facilities catch this and use
> superclass hashcodes when this occurs?
No - classes that use the hash code, such as HashMap, just stop
working, effectively.
They *can't* catch the broken code, really - they'd have to be able to
produce all other possible equal objects and check them all.