Когда это желаемо для не реализации toString () в Java?

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

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

Итак, относительно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+1 Майк C

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

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

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

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

Ну, он кое-что не понимает.

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

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

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

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

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

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

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

Примечание. Вы также можете разработать свой собственный внешний инструмент , чтобы открыть файл в проводнике Windows

. Или вы можете использовать плагин eclipse, например StartExplorer .

Примечания к MacOS:

zvikico упоминает :

В Mac OS X замените местоположение на / usr / bin / open , а аргументы должны будь просто $ {container_loc} .

Но Адам предостерегает :

Не работает - OSX, вам нужно заключить кавычки вокруг $ {container_loc} , иначе вы часто получаются странные сообщения об ошибках, потому что он не может справиться с пробелами в именах файлов.

Но user2036022 подробности :

вы можете использовать -R "$ {resource_loc}" в macosx как аргумент / usr / bin / open для согласования с другими подобными инструментами.

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

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

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

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

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

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