Каковы первоначальные причины ToString () в Java и .NET?

Question

В прошлом я использовал ToString() скромно и нашел его очень полезным во многих обстоятельствах. Тем не менее, мое использование этого метода вряд ли оправдывает использование этого метода не иначе как System.Object. Мое дикое предположение состоит в том, что в какой-то момент во время проведенной работы и совещаний, посвященных первоначальному проектированию платформы .NET, было решено, что необходимо - или, по крайней мере, чрезвычайно полезно - включить ToString() метод, который будет реализован всем в .NET Framework.

Кто-нибудь знает, какие были точные причины? Я пропускаю кучу ситуаций, когда ToString() оказывается достаточно полезным, чтобы быть частью System.Object? Каковы были первоначальные причины для ToString()?

Большое спасибо!

PS - Опять же: я не подвергаю сомнению метод или намекаю, что он бесполезен, мне просто интересно узнать, почему он так полезен, что его можно поместить в System.Object.

Примечание: представьте себе:

AnyDotNetNativeClass someInitialObject = new AnyDotNetNativeClass([some constructor parameters]);

AnyDotNetNativeClass initialObjectFullCopy = AnyDotNetNativeClass.FromString(someInitialObject.ToString());

Разве это не круто?

РЕД (1):

(A) - Судя по некоторым ответам, языки .NET унаследовали это от Java. Итак, я добавляю «Java» к теме и тегам. Если кто-то знает причины, по которым это было реализовано в Java, пожалуйста, пролите немного света!

(B) - Статическая гипотеза FromString против сериализации: конечно, но это совсем другая история, верно?

Answer 1

Первоначально он был добавлен в Object для целей отладки и ведения журнала. Вы можете сделать это, если посмотрите на JavaDoc для Object.toString (http://java.sun.com/javase/6/docs/api/java/lang/Object.html#toString()),, поскольку он выводит имя класса, после которого следует символ @, за которым следует шестнадцатеричное представление без знака хеш-кода объекта. вижу, что это очень полезно в журнале или консоли.

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

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

Answer 2

Не обсуждая его достоинств, я полагаю, что это имеет свои корни в вдохновляющем языке для C # - Java. Причина, по которой он был создан (для обоих языков), состояла в том, чтобы предоставить способ получить строковое представление экземпляра любого объекта, включая поддержку различных культур. Все просто.

Answer 3

Я могу вспомнить две технические причины для определения toString() на java.lang.Object.

• API PrintStream.print(Object) (например) зависит от Object.toString();

• Оператор конкатенации строк + зависит от Object.toString() в случае, когда один из операндов является ссылочным типом, не являющимся строкой.

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

Однако действительно удобно, что print (и т. Д.) И + конкатенация просто работают для всего. И я уверен, что именно поэтому Java была разработана таким образом.

РЕДАКТИРОВАТЬ - в ответ на этот вопрос из OP:

Статический гипотетический FromString против сериализации: конечно, но это совсем другая история, верно?

Предполагая, что я правильно анализирую ваш синтаксис ...

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

Answer 4

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