Каковы исходные причины ToString() в Java и .NET?

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

Кто-нибудь знает, каковы были точные причины? Я не хватает тонны ситуаций, когда 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 против Сериализации: конечно, но это совсем другая история, верно?

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

EDIT - в ответ на этот последующий вопрос из OP:

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

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

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

Ответ 4

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