One important decision you'll have to make when implementing a toString method is whether to specify the format of the return value in the documentation. It is recommended that you do this for value classes, such as phone numbers or matrices. The advantage of specifying the format is that it serves as a standard, unambiguous, human-readable representation of the object. This representation can be used for input and output and in persistent human-readable data objects, such as XML documents. If you specify the format, it's usually a good idea to provide a matching static factory or constructor
...more
Beware, this is much less often true than it sounds. Enough so that I would make the recommendation: Do not plan to do this except for a few, well-thought-out exceptions...
`toString()` is for _developer_-friendliness. There are many different ways to even represent numbers, dates, phone numbers, (doesn't matter if those are going into XML or JSON), and those all deserve a 1st-class, purpose-built serialization format and method for transferring between systems (or even storing for your later self, whose needs do change). Further, there are often multiple formats in use (e.g., your input dates might be in one format, while your output is a different format), and it's best to have explicit serializers (whether classes or methods) for each of those.
This is just as true for user-friendliness, too. The context in which these strings might show up can vary a lot (maybe the area code should be smaller than the rest of the phone number. should the country code be part of the string?) and `toString()` simply isn't the best tool to ensure each of your UIs can show the right string the right way.
Among the exceptions, are those objects that represent things that are strings by definition, that have one well-defined, correct string representation. An example of that are URIs; a string-based specification for resource identification.
I'd then say there's no global expectation (`Object` method to override) …