Override toString() when you want a mere mortal to be able to read something meanningful about the..

[Vishal Hegde]

Override toString() when you want a mere mortal to be able to read something meanningful about the objects of your class.


Courtesy : SCJP 6.0 (Luv you kathy for the awesome book)



Can someone please provide a simple example regarding this?

[Henry Wong]

When someone prints your object, the println() method calls the toString() method to get the string to print. So... do you want to override the toString() method so that you get something sensible printed to the screen? Or do you want your object to inherit the toString() method from the Object class (assuming that's your super class), and just get the name of your class and the hashcode?

Henry

[David Newton]

public class Foo {
    private String name;
    // Etc.
    @Override public String toString() {
        return super.toString() + "[name='" + name + "']";
    }
}

[Rob Spoor]

David Newton wrote:

public class Foo {
    private String name;
    // Etc.
    @Override public String toString() {
        return super.toString() + "[name='" + name + "']";
    }
}

You mean

return getClass().getName() + "[name=" + name + "]";

don't you? Or do you usually include the HEX hash code in your toString implementations?

[David Newton]

I *always* include it; without it I often have to fire up a debugger (which I almost never use) just to find out if an issue is coming from same/different object references. I can't think of a good reason not to include it by default. Although in real life I also almost always use some form of ToStringBuilder.