Quali sono i motivi originali di ToString() in Java e .NET?

Question

Ho usato il ToString() modestamente in passato e l'ho trovato molto utile in molte circostanze. Tuttavia, il mio utilizzo di questo metodo difficilmente giustificherebbe mettere questo metodo nientemeno che in System.Object. La mia ipotesi è che, ad un certo punto durante il lavoro svolto e le riunioni tenute per elaborare il progetto iniziale del framework .NET, è stato deciso che era necessario - o almeno estremamente utile - includere un metodo ToString() che sarebbe implementato da tutto nel framework .NET.

Qualcuno sa quali sono le ragioni esatte? Mi mancano un sacco di situazioni in cui lo ToString() risulta abbastanza utile da far parte di System.Object? Quali erano le ragioni originali per ToString()?

Grazie mille!

PS - Anche in questo caso: non sto mettendo in dubbio il metodo o insinuando che non è utile, sono solo curioso di sapere cosa lo rende così utile da collocare in System.Object.

Nota a margine - Immaginate questo:

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

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

Non sarebbe cool?

EDIT (1):

(A) - Sulla base delle risposte, sembra che i linguaggi .NET ereditato questo da Java. Quindi, aggiungo "Java" all'oggetto e ai tag. Se qualcuno conosce i motivi per cui questo è stato implementato in Java, per favore fai un po 'di luce!

(B) - Statico ipotetico FromString vs Serializzazione: certo, ma questa è una storia completamente diversa, giusto?

Answer 1

Inizialmente è stato aggiunto a oggetto a scopo di debug e di registrazione. È possibile dedurre questo se si analizza JavaDoc per Object.toString (http://java.sun.com/javase/6/docs/api/java/lang/Object.html#toString()), poiché restituisce il nome classe, seguito da @, seguito dalla rappresentazione esadecimale senza segno del codice hash dell'oggetto. L'unico posto in cui riesco a vedere questo è molto utile in un log o in una console.

Ma i creatori di Java hanno lasciato intenzionalmente questo metodo non-finale in modo che le sottoclassi potessero (e dovrebbero) sovrascriverle per produrre invece informazioni più specifiche per le sottoclassi. Avrebbero potuto semplicemente implementare la JVM in modo tale che, passando un oggetto in qualsiasi metodo che richiedesse una stringa, generasse quel valore hash sopra e lo passasse nel metodo, ma invece erano belli e lo implementarono come metodo che potevi così comodamente oltrepassare.

E il suo implementato a livello di oggetto in modo che si può tranquillamente assumere qualsiasi oggetto può essere scritto su un log/console. È un presupposto conveniente nel linguaggio Java.

Answer 2

Senza discutere dei suoi meriti, credo che questo abbia le sue radici nel linguaggio ispiratore per C# - Java. Il motivo per cui è stato creato (per entrambe le lingue) era quello di fornire un modo per ottenere una rappresentazione in stringa di un'istanza di qualsiasi oggetto, incluso il supporto per culture diverse. Semplice come quella.

Answer 3

Credo che fosse solo considerato utile che ogni oggetto può avere una rappresentazione di stringa, anche se solo a scopo di debug ...

Answer 4

Posso pensare a due motivi tecnici per la definizione di toString() su java.lang.Object.

• Il PrintStream.print(Object) API (per esempio) dipende Object.toString();

• L'operatore di concatenazione delle stringhe + dipende da Object.toString() nel caso in cui uno degli operandi sia un tipo di riferimento non String.

In alternativa, esso sarebbe stato possibile per definire un'interfaccia (diciamo) Printable che ha offerto un metodo toString() -come e definito sopra per richiedere un Printable. (E ciò eviterebbe la perplessità che sorge quando un principiante cerca di stampare un oggetto che non sovraccarichi toString()).

Tuttavia, è davvero conveniente che la concatenazione print (ecc.) E + funzioni per tutto. E sono sicuro che è per questo che Java è stato progettato in questo modo.

EDIT - in risposta a questa domanda followup dal OP:

Statico ipotetico fromstring vs serializzazione: certo, ma questa è tutta un'altra storia, giusto?

Supponendo che sto parsing la sintassi corretta ...

L'obiettivo di serializzazione scopo consiste nel fornire una rappresentazione piatta che può essere affidabile ed efficiente deserializzato. L'obiettivo di toString() è di fornire una rappresentazione testuale facile da leggere. In pratica, "facile da leggere" e "attendibilmente ed efficientemente deserializzabile" sono contraddittorie.