Re: why add toString() to a new class???
www.pulpjava.com wrote:
This is simple a good design practice. Being able to print out the
state of a class, as opposed to just the memory location reference it
consumes, can be extremely helpful when debugging and logging.
Tom Forsmo wrote:
You can add them when needed to debug the code. But as soon as you are
finished, it should be removed again.
I have heard the same thing about equals() as well. You should only
add these methods if they are an integral part of the functionality.
E.g. if you have a debug level log activity that requires printing
object states or you are doing a sort algorithm etc.
Eric Sosman wrote:
It depends on the "scope" of the class. ...
However, if you're writing a class with the intent to re-use
it, or even if it's custom-tailored for a particular application
but you think the application might be extended or changed, Tom's
advice is less applicable. The fact that a method isn't used today
doesn't mean it won't be used tomorrow, and IMHO it's a good idea
to implement all the "core" methods sensibly. Tom mentions omitting
equals() -- well, if you think anyone might ever want to store class
instances in a Set, you should consider whether Object's equals()
suffices or not. If you implement the Comparable interface, you
should ponder whether it's better warn users of your compareTo()
that it is "inconsistent with equals" or just go ahead and implement
equals(). And when you implement equals(), it's all but mandatory
to do hashCode() at the same time.
....
When writing a class,
including a clean and consistent implementation of "core" methods
like equals(), hashCode(), perhaps compareTo(), and, yes, toString()
can make the difference between assisting or inhibiting re-use.
All this focus on "debugging" obscures the real reason why you'd often want to
override equals(), hashCode(), compareTo() and toString(). (See _Effective
Java` by Joshua Bloch for more exposition.)
As Eric pointed out, equals(), hashCode() and compareTo() overrides are
necessary if an object is intended to be contained in a Collection (depending
on what type of Collection).
Most value objects (a.k.a. transfer objects) should override equals() and
hashCode(). They almost always model objects that should be compared by
value, not by location in the JVM.
toString() is useful for situations where an object makes itself known to a
user or other external component.
<p>Send this message to <%= person %></p> (or ${person})
If Person overrides toString() then this works as one would hope.
It's not necessarily about debugging or re-use, it's about use. For many
classes the intended use requires overriding these methods.
- Lew