The Artima Developer Community
Sponsored Link

clone() & toString()

Advertisement

Advertisement

This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

clone() & toString()

Posted by Ashish Sahni on 02 Oct 1998, 11:50 AM

> > Bill

> > I am a regular reader of your Design Techniques column. It is great. Thank you for all your efforts.

> > My question is that in you Worker.clone() method, why the name attribute is not copied?

> I didn't bother to clone the name variable, because it holds
> a reference to an immutable String object. Since no one can
> change the String object, it doesn't need to be cloned. Both
> Worker clones can share a reference to the same name String.
I have a question regarding the clone method which is not
directly related to the discussion above

A tutorial on the Javasoft site http://java.sun.com/docs/books/tutorial/java/more/objectclass.html
mentions the following

"Be careful: clone should not use new to create the clone and should not call constructors."

I was wondering why. As long as one gets a cloned object how should
it matter whether its created using new or java.lang.Object.clone()


> > Also I think all class should implement toString() method. My reason is very pratical. When you do debug, at any stage, by

> > System.out.println(worker.toString());

> > you can see the states of the instance. I have implemented the method in all my classes. I found it very helpful in my debugging process, expecially in the distributed computing envirronment.

> > Looking forword to hearing your comments.

> This is one I thought about. I wanted to hear what people
> would say about my leaving out overriding toString(). So
> far you are the only person who complained, but on the
> other hand, no one has said, "Rah, rah, rah, it's about time
> someone said you don't need to always override toString()."

> I left it out because in most of the Java classes I have
> written, I didn't override toString(), even though it
> suggests it in the Java specs and javadoc documentation.
> I have only overridden toString() when I was specifically
> needing to look at the output of toString(), usually for
> debugging purposes. That was rare, so I left it out of
> the idiom mostly just based on my own experience.
Bill, u must be very talented programmer to rarely
use debugging but for most of us its a very common thing.
I always see to it that the toString method of an
application specific class reflects the state of the object
by returning the variable/attribute name and their values in
a form that is readable( ofcourse ) AND understandable format.
java.util.Properties prints out the state of a Properties
object in a similar fashion.
If it printed out
@ ....
one would have to enumerate thru all the key/value pairs
and print them out.

I think it good Object Oriented design when the object
state is reflected as explicitly as possible cause
a lot of other folks might be using your code who might
require this feature even if one does not require it.

-Ashish

> So the question is, does anybody else out there have an
> opinion on toString()?

> bv






Replies:
  • toString() Reginald Braithwaite-Lee 08 Oct 1998, 7:22 AM (0)

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2009 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us