¿Cuáles son las razones originales para ToString() en Java y .NET?

Question

He usado ToString() modestamente en el pasado y lo he encontrado muy útil en muchas circunstancias. Sin embargo, mi uso de este método difícilmente justificaría poner este método en nada menos que System.Object. Creo que, en algún momento durante el trabajo realizado y las reuniones celebradas para presentar el diseño inicial del .NET Framework, se decidió que era necesario, o al menos extremadamente útil, incluir un método ToString() que sería implementado por todo en .NET Framework.

¿Alguien sabe cuáles fueron las razones exactas? ¿Me estoy perdiendo un montón de situaciones en las que ToString() es lo suficientemente útil como para ser parte de System.Object? ¿Cuáles fueron las razones originales de ToString()?

¡Muchas gracias!

PD - Nuevamente: no estoy cuestionando el método o insinuando que no es útil, solo tengo curiosidad por saber qué lo hace TAN útil como para colocarlo en System.Object.

Nota al margen - Imagine esto:

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

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

Esto no sería genial?

EDITAR (1):

(A) - Sobre la base de algunas respuestas, parece que los lenguajes .NET heredan esto desde Java. Entonces, estoy agregando "Java" al tema y a las etiquetas también. Si alguien sabe los motivos por los que esto se implementó en Java, por favor, ¡arroja algo de luz!

(B) - Static hypothetical FromString vs Serialización: seguro, pero esa es una historia bastante diferente, ¿no?

Answer 1

Fue añadida inicialmente a objeto para fines de depuración y de registro. Puede deducir esto si mira JavaDoc para Object.toString (http://java.sun.com/javase/6/docs/api/java/lang/Object.html#toString()), ya que emite el nombre de clase, seguido de @, seguido de la representación hexadecimal sin signo del código hash del objeto. El único lugar donde puedo ver que esto es muy útil es en un registro o consola.

Pero los creadores de Java intencionalmente dejaron este método como no final, por lo que las subclases podrían (y deberían) anularlo para producir más información específica de subclase. Podrían haber implementado la JVM de forma tal que al pasar un objeto a cualquier método que requiriera una cadena, generara ese valor hash arriba y lo pasara al método, pero en su lugar fueron agradables y lo implementaron como un método que usted podría convenientemente anular.

Y está implementado en el nivel Objeto para que pueda asumir con seguridad cualquier objeto se puede escribir en un registro/consola. Es una suposición conveniente en el lenguaje Java.

Answer 2

Sin discutir sus méritos, creo que esto tiene sus raíces en el lenguaje inspirador de C# - Java. La razón por la que se creó (para ambos idiomas) fue proporcionar una forma de obtener una representación de cadena de una instancia de cualquier objeto, incluido el soporte para diferentes culturas. Simple como eso.

Answer 3

supongo que sólo se consideró útil que cualquier objeto puede tener una representación de cadena, aunque sólo sea para fines de depuración ...

Answer 4

Puedo pensar en dos razones técnicas para definir toString() en java.lang.Object.

• El API PrintStream.print(Object) (por ejemplo) depende de Object.toString();

• El operador de concatenación de cadenas + depende de Object.toString() en el caso en que uno de los operandos sea un tipo de referencia que no sea de cadena.

Como alternativa, se habría sido posible para definir una interfaz (por ejemplo) Printable que ofrecía un método toString() -como y define lo anterior para requerir una Printable. (Y eso evitaría la confusión que surge cuando un novato intenta imprimir un objeto que no sobrecarga toString()).

Sin embargo, es realmente conveniente que la concatenación print (etc) y + funcione para todo. Y estoy seguro de que es por eso que Java fue diseñado de esa manera.

EDITAR - en respuesta a esta pregunta de seguimiento del Programa Operativo:

estático fromstring hipotética vs serialización: seguro, pero eso es una historia muy diferente, ¿verdad?

Suponiendo que estoy al analizar la sintaxis correcta ...

El objetivo de la serialización de objetos es proporcionar una representación plana que puede ser fiable y eficiente deserialized. El objetivo de toString() es proporcionar una representación textual que sea fácil de leer. En la práctica, "fácil de leer" y "confiable y eficientemente deserializable" son contradictorios.