Когда желательно не реализовывать toString () в Java?

Question

Ведущий разработчик моего проекта обратился к реализациям проекта toString () как к "чистой лжи" и надеется удалить их из базы кода.

Я сказал, что это будет означать, что любой клиент, желающий отобразить объекты, должен будет написать свой собственный код для преобразования объекта в строку, но на это ответили "да, они будут".

Теперь, в частности, объекты в этой системе являются графическими элементами, такими как прямоугольники, круги и т. Д., И текущее представление должно отображать x, y, масштаб, границы и т. Д. *

Так где же находится толпа?

Когда и когда не следует реализовывать toString?

Answer 1

+ 1 Майк С

Помимо своей полезности для отладки, toString () является бесценным инструментом для понимания точки зрения автора класса на экземпляр.

FWIW, если вывод toString отличается от того, что вы ожидаете увидеть (вежливые спецификации), вы сразу поймете, что что-то пошло не так.

Answer 2

Если есть проблема с существующими реализациями toString(), разработчик должен решить проблему. Сказать, что текущие реализации - это «чистая затея», и удаление их активно приносит вред, если существующие toString() методы необычно плохо написаны.

Я бы решительно отговорил разработчика отказаться от любого работающего toString() метода.

Answer 3

Лично я реализую их, когда собираюсь использовать объекты в JList, JTable или другой структуре, которая использует toString () ИЛИ когда я отлаживаю (да, eclipse имеет средства форматирования отладки, но toString () проще) .

Возможно, вы можете отозвать, что многие классы JDK имеют toString (). Должны ли они быть удалены? ;)

Answer 4

Я бы определенно сохранил реализации toString (), особенно для целей отладки. Как разработчик C ++, я бы хотел, чтобы в C ++ все было так же просто, как и в Java (перегрузка операторов может быть проблемой).

Answer 5

Чтобы быть справедливым, сказал разработчик здесь, но не ведущий разработчик в любом смысле.

Исходная проблема не обязательно о toString (), но о втором методе paramString: «Со всей конкатенацией строк и проверкой нулевых значений paramString является магнитом ошибки».

См. http://code.google.com/p/piccolo2d/issues/detail?id=99

Answer 6

Я сказал, что это будет означать что любые клиенты, желающие отобразить объекты должны будут написать свои собственный код для преобразования объекта в строка, но ответили «Да, они будут».

Это не вопрос, на который можно ответить изолированно ... вам следует спросить клиентов (или людей, которые их пишут), что они думают об этой идее. Если бы я использовал библиотеку Java и полагался на ее перегрузки toString () для отладки, я был бы весьма раздражен, если бы разработчики библиотеки решили их очистить.

Answer 7

Это имеет смысл, потому что у вас всегда есть проблемы с toStrings, показывающими слишком мало или слишком много информации.

Возможно, вашей команде имеет смысл использовать ToStringBuilder в Jakarta Commons Lang:

System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));

, который анализирует объект и печатает открытые поля.

http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/builder/ToStringBuilder.html

Answer 8

Я бы сказал, что вам следует реализовать toString, если это ожидаемый вариант использования или требование, для отображения объекта в виде строкового представления (либо в журналах, на консоли, либо в каком-либо дереве отображения).

В противном случае, я согласен с разработчиком - каждый раз, когда вы что-то меняете, toString может сломаться. Возможно, вам следует быть осторожным с нулями и т. Д.

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

Я согласен с jsight в том, что если они уже написаны и написаны прилично, оставьте их как минимум до тех пор, пока они не будут мешать (например, если вы фактически добавите поле в класс).

Answer 9

В целях отладки никто не может победить toString. Это практично как в отладчике, так и в простых отладочных отпечатках. Убедитесь, что он отображает все поля, на которых основаны ваши методы equals и hashCode, если вы также переопределяете их!

Для отображения конечным пользователям я бы не стал использовать toString. Для этого я думаю, что лучше написать другой метод, который выполняет правильное форматирование, и i18n, если вам это нужно.

Answer 10

Хорошо для отладки. Но если вы хотите отобразить данный объект в виде строки для конечного пользователя, вы никогда не должны использовать реализацию toString (), а предоставлять для этого собственный метод.

Так что относительно

Я сказал, что это будет означать что любые клиенты, желающие отобразить объекты должны будут написать свои собственный код для преобразования объекта в строка, но ответили «Да, они будут».

Я согласен с руководителем вашей команды. Если вы хотите отобразить объект для любого клиента, используйте пользовательскую реализацию. Если вы хотите использовать его в целях отладки, используйте toString ().