Be Honest: Do you implement hashCode(), equals(), and toString() for every class you write?

[Danno]

Just curious

 

[Lionel]

Just curious

Not even close .

 

[Matt Humphrey]

Just curious

Yes, for exactly every class that needs a custom implementation. A
class-specific meaning is not necessarily needed for every object.

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Just curious

toString: often

equals and hashCode: sometimes

Arne

 

[Manish Pandit]

I use toString for the transfer objects, and put the Apache Commons
ToStringBuilder.reflectionToString(this) in the overriden method.
However, this is very expensive operation and I control this via log4j
levels, like logger.debug(myObject) instead of going lose cannon
system.out.println

I use equals rarely, when I have to compare DTOs based on a set of
attributes - for example, comparing 2 persons based on their firstNames
being same, ignoring other attributes.

hashCode - never.

-cheers,
Manish

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I use equals rarely, when I have to compare DTOs based on a set of
attributes - for example, comparing 2 persons based on their firstNames
being same, ignoring other attributes.

hashCode - never.

You know what you should do ...

Arne

 

[Manish Pandit]

You know what you should do ...

eh?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

eh?

If you implement equals, then you should implement hashCode !

Arne

 

[Manish Pandit]

Ah

In conjunction with equals() - yes, standalone - never.

-cheers,
Manish

 

[Mark Jeffcoat]

Just curious

You'll know when you need equals()... most things
don't get compared, so there's usually no reason to
bother.

Once you've put in your own equals() method, you really
need to override hashCode(), too. But pre-mature optimization
is evil, so here's the one I always use pre-profiling:

public int hashCode() {
return 0;
}


I'm not kidding.

 

[Patricia Shanahan]

Just curious

Definitely not. I implement toString when there is a short, but
interesting, String representation. I stay with the Object equals and
hashCode unless the class has a strong natural concept of value
equality, which generally involves immutability.

Patricia

 

[Danno]

Definitely not. I implement toString when there is a short, but
interesting, String representation. I stay with the Object equals and
hashCode unless the class has a strong natural concept of value
equality, which generally involves immutability.

Patricia

You are more eloquent than I am Patricia, that is exactly what I do.

 

[Chris Uppal]

[In general it is a bad idea to put the question into the subject line without
repeating it in the main body of the text].

Just curious

No, certainly not. That would be a very bad mistake.

It's always worth /considering/ overriding toString(), but rarely actually
worthwhile. It would often be an /error/ to override equals()/hashCode().

-- chris

 

[GenxLogic]

Well,
toString() methods is overriden very frequently. but equals() and
hasshCode() depends upon the need and use fo the class. 90% i have
skipped both functions.

Deepak

[In general it is a bad idea to put the question into the subject line without
repeating it in the main body of the text].

Just curious

No, certainly not. That would be a very bad mistake.

It's always worth /considering/ overriding toString(), but rarely actually
worthwhile. It would often be an /error/ to override equals()/hashCode().

-- chris

 

[Daniel Dyer]

You'll know when you need equals()... most things
don't get compared, so there's usually no reason to
bother.

Once you've put in your own equals() method, you really
need to override hashCode(), too. But pre-mature optimization
is evil, so here's the one I always use pre-profiling:

public int hashCode() {
return 0;
}

Personally, I'd never implement hashCode this way because the effort to do
it properly is so minimal. Premature optimisation may be evil but, if
there are two ways to do something, choosing the better way is not
necessarily premature optimisation - it could just be doing things right
first time around.

If you are going to be putting these objects into a hashed collection
(maps and sets), you're effectively turning that collection into a list
with this hashCode implementation, and I'm assuming that you're not using
lists everywhere until the profiler tells you that you need a better data
structure.

You can generally write a reasonable hashCode implementation in a few
lines following the approach that Josh Bloch outlines in Effective Java.
IDEs such as IDEA can automatically generate matching equals and hashCode
methods for you. Since this is a general purpose approach and trivial to
do I don't see it as premature optimisation. If you were talking about
writing a hashCode implementation that is optimised to the specific usage
patterns of your application, then I would agree that that would probably
qualify as optimisation that is best left until there is a demonstrated
need.

Dan.

 

[Chris Uppal]

Once you've put in your own equals() method, you really
need to override hashCode(), too. But pre-mature optimization
is evil, so here's the one I always use pre-profiling:

public int hashCode() {
return 0;
}


I'm not kidding.

You should be.

/Anything/ would be better than that. Throw a runtime exception -- at least
that would guarantee that you weren't depending on having a working hashCode()
without realising it.

-- chris

 

[Patricia Shanahan]

You should be.

/Anything/ would be better than that. Throw a runtime exception -- at least
that would guarantee that you weren't depending on having a working hashCode()
without realising it.

It is a functionally correct hashCode. If a and b reference equal
instances of the class, a.hashCode() is equal to b.hashCode(). If there
is any problem with it, it will show as poor hash structure performance.

I assume that if Mark found poor hash table performance during
profiling, he would upgrade the hashCode() method for the key class.

That said, when I'm writing an equals(), I know exactly which features
must be equal for two instances to be considered equal, which is the
only difficult part of writing a good hashCode(). I just write the two
methods together.

Patricia

 

[Matt Humphrey]

I assume that if Mark found poor hash table performance during
profiling, he would upgrade the hashCode() method for the key class.

That said, when I'm writing an equals(), I know exactly which features
must be equal for two instances to be considered equal, which is the
only difficult part of writing a good hashCode(). I just write the two
methods together.

I agree with this approach in that objects for which content equality is
meaningful (which must be implemented and therefore understood) have an
easily implementable hashCode.

My question is, what is a good first implementation of compound hashCode?
For objects that have simple fields a, b, c I tend to use

a.hashCode ^ b.hashCode ^ c.hashCode

And for compositions, accumulating hashCodes of elements over ^.

The idea is to get the greatest possible spread while ensuring that two
objects that are equal will produce the same value.

Are there better functions to use? What are your rules of thumb?

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Thomas Hawtin]

My question is, what is a good first implementation of compound hashCode?
For objects that have simple fields a, b, c I tend to use

a.hashCode ^ b.hashCode ^ c.hashCode

That doesn't work well if the hash codes of a, b and c are often equal,
a, b and c are often permutations, or whatever.

You could take you lead from String and do something like:

@Override
public int hashCode() {
int h = a.hashCode();
h = h*31 + b.hashCode();
h = h*31 + c.hashCode();
return h;
}

Tom Hawtin

 

[Lord0]

toString(): Often, especially for DTO's etc

equals(), hashcode(): Seldom. I may override equals(), again probs for
DTO's. If I override equals() then I will always override hashcode()

Lord0