Помню, как когда только-только начинал работать с языком Java, был жутко обрадован наличию метода toString у каждого объекта - "как же удобно будет теперь отлаживать программы", подумал я.

Однако, чем дольше работаю с JVM-экосистемой, тем больше убеждаюсь, что, как и null-указатели, toString при кажущемся удобстве на самом деле несёт больше проблем, чем пользы. Поскольку метод имеет реализацию по умолчанию, очень сложно следить за тем, где он был явно переопределён, а где - нет. Более того, этот метод не имеет чётко определённой семантики, в результате чего нередко можно встретить проекты, где toString имеет разный смысл в зависимости от класса: где-то он трансформирует объект в строку для логирования, где-то - в строку для использования в интерпретаторе и так далее.

Разумеется, можно и нужно определять сторонние методы в зависимости от задачи, но когда сама экосистема языка даёт такой метод в качестве одного из основных инструментов, то волей-неволей приходится иметь дело с проектами и библиотеками, которые используют его некорректно.

В ФП-сообществе уже достаточно давно придумали альтернативу toString в виде тайпкласса Show (ссылка), который сигнализирует о наличии у класса возможности превращения в строку. В нашей команде для логирования объектов и их полей можно использовать исключительно Show, чтобы не допустить ненарочного попадания чувствительных данных в логи.