Re: why add toString() to a new class???
Eric Sosman wrote:
(However, his warnings that
the code might be "misused" seem contradictory; how can anyone
"misuse" an unused method?)
What I was thinking about here was situations where code not relevant to
the functionality can be used in other places or situations, by for
example a junior programmer, without realising the consequence of using
it there. E.g. a test method of equals() which is deliberately incorrect
could be forgotten there, the error it possibly introduces could go
unnoticed for a long time to when one find an error spend lots of time
figuring out. The same could happen with toString() but the consequence
could be a security risk of information being printed to console or a
log which should not be or just wasted time on printing large data
structures which should not be printed in detail etc.
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.
What you are talking about here are methods relevant to the
functionality, so then you should implement them.
But if you don't use the classes in these, or similar situations, the
added code is just litter.
If the history of software teaches anything, it's that systems
evolve in ways not anticipated by the original authors -- sometimes
smoothly, sometimes with unpleasant surprises. 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.
Could be, but in most real cases I disagree. Because if the design is
good, then those methods are added where needed (i.e. where
extensibility is designed into the code), not all over the place just in
case.
tom