Often during design discussions or workshops someone will write down a word that is meaningful in the domain, perhaps in a box in a collaboration diagram, or as a piece of data, or being shown in the user interface.  Recently I've been asking "what is that the toString() of?" when I see these words.  This really stirs programmers who are designing, making them think about all the responsibilities and related concepts rather than escaping with a string that will be held somewhere.

Yes, I know a good example is needed.  Later - I'm tired!  Plus links to stuff on "finding" objects.

-- BruceAnderson

Hey, where's that example you promised? -- TaralDragon Sorry Taral, but the next post makes the point perfectly -- BruceAnderson

That the string may be found "as a piece of data, or being shown in the user interface" suggests that the question is "what domain object is that string a representation of?". For example, if a GUI has a box which says "red", which object is it that is red, or knows what the colour is. The ToStringQuestion seems to be a way of getting from a surface view of a system to its internal structure. It makes the assumption that there is a straightforward mapping between visible and internal entities, or at least it makes the developers think about whether there is, can be and should be.

''For those who aren't familiar with toString(): http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#toString()''
----

On a related note, one of the things that seems to have gone by the wayside in Java (at least from the perspective of a SeasonedSmalltalker) is the difference between #displayString and #printString.  The audience for the #displayString of an object is application users.  The audience for the #printString of an object is application developers.  In both cases it is the object's responsibility to decide how to represent itself as a String.  I think most people interpret the Java toString() method as #displayString.  I still think it is very useful, regardless of language, to have the two different representations for the two different audiences.  And yes, I have been criticized for using this Smalltalk idiom in Java - so sue me. -- RandyStafford

One of the most important principals of software design is, "don't provide something in a base class or interface that isn't necessary."  Smalltalk's #displayString is such an example.  You see, Smalltalk is showing its age - it was invented during a time when a simple string is good enough for display purposes.  Today's software requires multiple strings available for display purposes, formatted differently depending on the viewer.  Therefore, Java doesn't deserve such treatment.  If you need toDisplayString, create it.  If you need toHtmlString, create it.  Better yet, in your architecture, create an OurObject that extends from Object, and add all the gnifty things your world needs. -- MarkFister

''Let's not forget the always-interesting #storeString. The "audience" for storeString is other objects, who wish to recreate the object. I find it *very* useful to ask java developers what the storeString of an object is, especially given that the Java environment often makes the answer quite tedious to reconstruct. -- TomStambaugh''

----------------------------------------------
I HaveThisPattern in both cases. For #displayString I have ended up with a ''Titled'' interface whose single ''title'' property returns a string suitable for use as a label or caption (and as a key for an icon or i18n text). The original use was for objects appearing in the user interface, but it's also proved handy for debug traces. 

After a lot of piecemeal tinkering with #storeString I have ended up subclassing all persistable objects from a ''_TypedNode'' class with a ''valueStrings'' method returning round-trippable stringifications of any children that are not themselves ''_TypedNode''s. Any instance is thus guaranteed to be (de)stringifiable as a whole and can readily be persisted as eg XML. (This incidentally complies with EricRaymond's recommendation in TheArtOfUnixProgramming that storage and communication should be string-based rather than binary).  
-- DavidWright

----

I HaveThisPattern in both cases. I interpret toString() as targeting the application programmer and use it in stacktraces and log messages (we do no i18n on error messages for the application developer and assume english - otherwise you would have to i18n the javadoc too). And something like #displayString for end user display has ended up in an interface too (providing a Locale object for i18n).
-- GunnarZarncke