When is it desired to not implement toString() in

Question

A lead developer on my project has taken to referring to the project's toString() implementations as "pure cruft" and is looking to remove them from the code base.

I've said that doing so would mean that any clients wishing to display the objects would have to write their own code to convert the object to string, but that was answered with "yes they would".

Now specifically, the objects in this system are graphic elements like rectangles, circles, etc and the current representation is to display x, y, scale, bounds, etc...

So, where does the crowd lie?

When should you and when shouldn't you implement toString?

Answer 1

It is good for debugging purposes. But if you want to display given object as a string to the end user you should never use toString() implementation but provide custom method for that.

So regarding

I've said that doing so would mean that any clients wishing to display the objects would have to write their own code to convert the object to string, but that was answered with "yes they would".

I agree with your team lead. If you want to display object to any client use custom implementation. If you want to use it for debugging purposes use toString().

Answer 2

I've always made sure that my classes implemented toString.

It provides a simple way of debugging the current state of the class when I'm debugging and when I'm logging errors, I can include it into my log messages.

Answer 3

I would argue the opposite that toString() should be overriden judiciously. The default toString() implementation is very uninformative and basically useless. A good toString() implementation can give a developer a very useful view of the contents of the object at a glance. You may not have to put everything in there but at least the important stuff. I think your lead developer should be actually coding and adding features rather than worrying about "cruft".

Answer 4

I think the answer depends on how complicated your toString() methods are, how much work they require to maintain, and how often they get used. Assuming you use toString() often for logging and debugging it doesn't make much sense to remove these methods. But if they are rarely used and require a lot of work to maintain each time something changes in your code, then there is perhaps a valid argument for getting rid of all or some of the toString() methods.

You mentioned something about clients needing to display these objects. From this I'm guessing your code is or contains some kind of library or API that other developers will use. In this case I highly recommend you maintain useful toString() implementations. Even if you don't do a lot of logging and debugging, your clients might and they will definitely appreciate having useful toString() methods that they don't have to write and maintain themselves.

Answer 5

I would only implement it for more complex objects where client code doesn't care about the fine grained details of the object state, but rather care about some more human understandable, sense making message, that summarizes what is going on, state wise...

For everything else, like JavaBeans, I would expect client code to throw my object into a ToStringBuilder method or similar, if it needs to do low-level debugging.

ToStringBuilder.reflectionToString(myObject);

Or client code should just call standard property getters and log the way they like...

Answer 6

In general, toString() is good stuff. In particular, it is quite useful for debugging.

Implementing toString() is not without costs and risks. Like all code, toString() implementations must be maintained with the rest of the code. This means keeping toString() in sync with class fields. For example, when a field is added or removed, toString() should be updated appropriately (you should be doing this already for methods like hashCode() and equals()).

Implementing toString() incurs risks as well. For example, suppose that two classes in your system have references to instances of the other (a bi-directional link), then an invocation of toString() could lead to a stack overflow due to unbounded recursion as the toString() implementation in each class invokes the toString() implementation of the other class.

If your system has a significant number of out-of-sync toString() methods, or methods that cause bugs like stack overflows, then your colleague might have a reasonable point. Even in such a case, I would simply comment-out the buggy toString() methods and leave them in the code. Each toString() method could be uncommented and updated individually as needed in the future.