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

Question

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

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

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

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

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

Answer 1

Какой вред они наносят? Зачем их удалять, если они есть? Я считаю, что toString () чрезвычайно полезен при создании операторов отладки.

Лично я всегда ошибался бы из-за наличия работоспособного метода toString (). Так мало работы, чтобы написать.

Answer 2

Удаление хорошо написанных (или даже наполовину прилично написанных) методов toString () - это просто безумие, ИМО. Да, мне часто лень их писать (так как часто объекты не заканчиваются тем, что их используют в любом случае), но их чрезвычайно удобно иметь.

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

Answer 3

Я всегда следил за тем, чтобы мои классы реализовали toString.

Он предоставляет простой способ отладки текущего состояния класса, когда я отлаживаю и когда я регистрирую ошибки, я могу включить его в свои сообщения журнала.

Answer 4

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

Answer 5

Я бы сказал, что toString () должен быть переопределен разумно. Реализация по умолчанию toString () очень неинформативна и в основном бесполезна. Хорошая реализация toString () может дать разработчику очень полезный взгляд на содержимое объекта с первого взгляда. Вы, возможно, не должны помещать все туда, но по крайней мере важные вещи. Я думаю, что ваш ведущий разработчик должен на самом деле кодировать и добавлять функции, а не беспокоиться о «краже».

Answer 6

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

Для всего остального, такого как JavaBeans, я бы ожидал, что клиентский код выбросит мой объект в метод ToStringBuilder или аналогичный, если для этого требуется отладка низкого уровня.

ToStringBuilder.reflectionToString(myObject);

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

Answer 7

В общем, toString() это хороший материал. В частности, это весьма полезно для отладки .

Реализация toString() не обходится без затрат и рисков . Как и весь код, toString() реализации должны поддерживаться с остальной частью кода. Это означает синхронизацию toString() с полями классов. Например, когда поле добавляется или удаляется, toString() следует соответствующим образом обновить (вы должны делать это уже для таких методов, как hashCode() и equals()).

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

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

Answer 8

Я всегда автоматически генерирую методы toString () для всех моих POJO s, DTO s и / или любого объекта, который содержит постоянные данные. Для частных внутренних свойств хорошая практика ведения журнала должна сделать свое дело.

Всегда не забывайте заменять в методах toString пароли и другую полезную информацию на [Omitted] (или что-то похожее на верхний секретный характер)

Answer 9

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

Вы упомянули что-то о клиентах, которым необходимо отображать эти объекты. Исходя из этого, я предполагаю, что ваш код содержит или содержит какую-то библиотеку или API, которые будут использовать другие разработчики. В этом случае я настоятельно рекомендую вам поддерживать полезные реализации toString (). Даже если вы не занимаетесь ведением логов и отладок, ваши клиенты могут и они обязательно оценят наличие полезных методов toString (), которые им не нужно писать и обслуживать самостоятельно.

Answer 10

Ну, он что-то делает.

Не могу сказать, что toString () слишком полезен. Для презентации вам понадобятся другие инструменты.

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

Не понимаю зачем удалять, если уже написано