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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

ToStringBuilder.reflectionToString(myObject);

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

Что ж, он действительно строит дело.

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

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

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

Ответ 10

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

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

Ответ 11

+1 Майк С

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

FWIW, если вывод toString отличается от того, что вы ожидаете увидеть (любезность spec docs), вы сразу узнаете, что что-то пошло не так.

Ответ 12

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

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

Ответ 13

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

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

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

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

Ответ 14

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

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

Ответ 15

Это имеет смысл, потому что у вас всегда есть проблемы с 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

Ответ 16

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

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

Ответ 17

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

Оригинальная проблема не обязательно о toString(), но о втором методе paramString: "При всей своей конкатенации строк и проверке нулевого значения paramString является магнитом ошибки".

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

Ответ 18

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

Ответ 19

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

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

Ответ 20

реализовать всегда:) Как упоминалось выше, это бесценно для отладки.

Ответ 21

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

Так что в отношении

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

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

Ответ 22

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

Ответ 23

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

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

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

Итак, что мы можем сделать, чтобы решить эти проблемы, не удаляя метод в целом? Ответ заключается в том, чтобы автоматически сгенерировать его. Project Lombok @ToString аннотация может автоматически генерировать метод toString для вас во время компиляции, который включает в себя любую комбинацию полей, которые вы выбираете.

Основной пример использования:

@ToString
public class Foo {
    private int i = 0;
}

Что станет эквивалентно следующему во время компиляции:

public class Foo {
    private int i = 0;

    public String toString() {
        return "Foo(i=" + this.i + ")";
    }
}

Ответ 24

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