Quando si desidera non implementare toString() in Java?
https://stackoverflow.com/questions/1161228
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Uno sviluppatore principale del mio progetto ha iniziato a riferirsi alle implementazioni toString() del progetto come "puro cruft" e sta cercando di rimuoverle dal codice base.
Ho detto che ciò significherebbe che tutti i client che desiderano visualizzare gli oggetti dovrebbero scrivere il proprio codice per convertire l'oggetto in stringa, ma la risposta è stata "sì, lo farebbero".
Nello specifico, gli oggetti in questo sistema sono elementi grafici come rettangoli, cerchi, ecc. e la rappresentazione corrente consiste nel visualizzare x, y, scala, limiti, ecc...
Allora, dove giace la folla?
Quando dovresti e quando non dovresti implementare toString?
Soluzione
Che male fanno? Perché rimuoverli se li avete? Trovo toString () estremamente utile quando si emettono dichiarazioni di debug.
Personalmente, sempre sbagliare sul lato di avere un metodo toString lavorabile (). Così poco lavoro da scrivere.
Altri suggerimenti
Rimozione ben scritto (o anche a metà strada decentemente scritta) toString () metodi è pura follia, IMO. Sì, sono spesso troppo pigro per scrivere queste (come spesso gli oggetti non finiscono per avere li ha usati in ogni caso), ma sono estremamente comodo avere.
Io davvero non riesco a pensare a un buon motivo per voler sbarazzarsi di questi.
Ho sempre fatto in modo che le mie classi implementate toString.
Si fornisce un modo semplice di debug dello stato attuale della classe quando sto debug e quando sto accedendo errori, posso includerlo nei miei messaggi di log.
I terrei le implementazioni toString(). Essi hanno un valore inestimabile quando si tratta di debug, e possono fare per il buon testo alt per i componenti grafici.
direi il contrario che toString () deve essere sovrascritto con giudizio. L'implementazione predefinita toString () è molto uninformative e sostanzialmente inutile. Un'implementazione buon toString () può dare uno sviluppatore una visione molto utile dei contenuti dell'oggetto a colpo d'occhio. Non si può avere a mettere tutto in là, ma almeno le cose importanti. Penso che il vostro capo sviluppatore dovrebbe essere in realtà la codifica e l'aggiunta di funzionalità piuttosto che preoccuparsi di "cruft".
Vorrei implementare solo per gli oggetti più complessi in cui il codice cliente non si preoccupa per i piccoli dettagli a grana fine dello stato dell'oggetto, ma piuttosto si preoccupano un po 'più umano comprensibile, percepire facendo messaggio, che riassume ciò che sta succedendo, lo stato saggio ...
Per tutto il resto, come JavaBeans, mi sarei aspettato codice del client di gettare il mio oggetto in un metodo ToStringBuilder o simili, se ha bisogno di fare il debug di basso livello.
ToStringBuilder.reflectionToString(myObject);
o il codice cliente deve solo chiamare getter proprietà standard e registrare il modo in cui piace ...
Generalmente, toString() è roba buona.In particolare, lo è abbastanza utile per il debug.
Implementazione toString() non è senza costi E rischi.Come tutto il codice, toString() le implementazioni devono essere mantenute con il resto del codice.Questo significa mantenere toString() in sincronia con i campi della classe.Ad esempio, quando un campo viene aggiunto o rimosso, toString() dovrebbe essere aggiornato in modo appropriato (dovresti già farlo per metodi come hashCode() E equals()).
Implementazione toString() corre dei rischi anche.Ad esempio, supponiamo che due classi nel tuo sistema abbiano riferimenti a istanze dell'altra (un collegamento bidirezionale), quindi un'invocazione di toString() potrebbe portare a un overflow dello stack a causa della ricorsione illimitata come il toString() l'implementazione in ogni classe invoca il toString() implementazione dell'altra classe.
Se il tuo sistema presenta un numero significativo di file non sincronizzati toString() metodi o metodi che causano bug come overflow dello stack, quindi il tuo collega Potrebbe avere un punto ragionevole.Anche in un caso del genere, lo farei commenta semplicemente il buggy toString() metodi e lasciarli nel codice.Ogni toString() il metodo potrebbe essere decommentato e aggiornato individualmente secondo necessità in futuro.
Ho sempre Generazione automatica toString) metodi di tutti i miei POJOs, DTOs e / o qualsiasi oggetto che contiene i dati persistenti (. Per le proprietà interne private buona pratica di registrazione dovrebbe fare il trucco.
Ricordarsi sempre di sostituire in toString metodi password e altre informazioni sesitive con [Omitted] (o qualcosa di simile di top natura secernono)
Bene, lo fa cosa stramge.
Non posso dire toString () è troppo utile. Per la presentazione avrete bisogno di altri strumenti.
Ma toString () è molto utile per il debugging, perché si poteva vedere il contenuto di collezioni.
Non capisco il motivo per rimuoverlo se è scritto già
Credo che la risposta dipende da quanto complicato tuo toString () I metodi sono, quanto lavoro di cui hanno bisogno per mantenere, e quanto spesso si abitua. Supponendo che si utilizza toString (), spesso per la registrazione e il debug non ha molto senso per rimuovere questi metodi. Ma se vengono usati raramente e richiedono un sacco di lavoro per mantenere ogni volta che cambia qualcosa nel codice, allora non è forse un argomento valido per sbarazzarsi di tutti o alcuni dei toString () metodi.
Hai accennato qualcosa circa i clienti che hanno bisogno di visualizzare questi oggetti. Da questo Sto indovinando il codice è o contiene una sorta di biblioteca o API che altri sviluppatori useranno. In questo caso mi raccomando a mantenere toString utile) implementazioni (. Anche se non si fa un sacco di logging e debugging, i vostri clienti potrebbero e saranno sicuramente apprezzare avendo toString utile () i metodi che non devono scrivere e mantenere se stessi.
1 Mike C
Al di là la sua utilità per il debug, il toString () è uno strumento prezioso per comprendere prospettiva dell'autore di classe dell'istanza.
FWIW, se l'uscita del toString è diverso da quello che vi aspettate di vedere (documenti di cortesia spec) saprete rightaway qualcosa è andato storto sul serio.
Personalmente, implemento loro quando ho intenzione di usare gli oggetti in un JList, JTable, o altra struttura che utilizza toString () o quando sto debug (sì, Eclipse ha formattatori di debug ma toString () è più facile) .
Forse si può sparare alla schiena che molte classi JDK hanno toString (). Dovrebbero essere rimossi pure? ;)
Direi che è necessario implementare toString se questo è un caso d'uso previsto o requisito, per visualizzare l'oggetto come rappresentazione di stringa (sia in ceppi, sulla console, o un qualche tipo di albero di visualizzazione).
In caso contrario, sono d'accordo con lo sviluppatore - ogni volta che si cambia qualcosa, il toString può rompere. Potrebbe essere necessario essere attenti a valori nulli, ecc.
Molte volte, però, è di fatto utilizzato in debug o in registrazione, in modo che non è ovvio che essi dovrebbero essere lasciati fuori a tutti.
Sono d'accordo con jsight che se sono già scritti, e scritto decentemente, lasciarli in almeno fino a quando non ottenere nel modo (come in realtà si aggiunge un campo a una classe).
Per scopi di debug, nessuno può battere toString. È pratico sia in un debugger, e in semplici stampe di debug. Assicurarsi che visualizza tutti i campi che i vostri equals e hashCode metodi si basano su, se si ignora quelli pure!
Per la visualizzazione agli utenti finali, non vorrei usare toString, però. Per questo, penso che sia meglio scrivere un altro metodo, che fa la formattazione corretta, e i18n se avete bisogno di questo.
Si fa buon senso perché si ha sempre problemi con toStrings che mostrano informazioni troppo poco o troppo.
Si può avere senso per la tua squadra per utilizzare la ToStringBuilder a Jakarta Commons Lang invece:
System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
che introspetta l'oggetto, e stampa i campi pubblici.
ho detto che così facendo avrebbe significato che tutti i clienti che desiderano visualizzare gli oggetti avrebbero dovuto scrivere il loro proprio codice per convertire l'oggetto da stringa, ma che è stato risposto con "Sì, sarebbe".
Questa non è una questione che può essere risolta in isolamento ... si dovrebbe chiedere i clienti (o le persone loro scrittura) cosa pensano di questa idea. Se stavo usando una libreria Java e basandosi sulla sua toString () sovraccarichi per il debug, sarei piuttosto seccato se gli sviluppatori della biblioteca ha deciso di eliminare loro.
Per essere onesti, ha detto lo sviluppatore qui, ma non portare sviluppatore in ogni senso.
Il problema originale non è necessariamente di toString (), ma di un secondo metodo paramString: "Con tutta la sua concatenazione di stringhe e controllo valore nullo, paramString è un magnete insetto."
http://code.google.com/p/ piccolo2d / temi / dettaglio? id = 99
avrei sicuramente mantenere il toString () implementazioni, in particolare a scopo di debug. Come sviluppatore principalmente C ++, vorrei che le cose erano facili in C ++ come sono in Java sotto questo aspetto (l'overloading degli operatori può essere un dolore).
Se c'è un problema con le implementazioni esistenti toString(), lo sviluppatore dovrebbe risolvere il problema. Dicendo le attuali implementazioni sono tutti "cruft pura" e la loro rimozione è attivamente facendo danno, a meno che i metodi toString() esistenti sono non comune scritto male.
Vorrei con forza scoraggiare lo sviluppatore di rimuovere qualsiasi metodo toString() funzionante.
implementare sempre :) Come accennato in precedenza, è prezioso per il debugging.
E 'un bene per scopi di debugging. Ma se si desidera visualizzare dato oggetto come una stringa per l'utente finale non si dovrebbe mai usare toString) implementazione (ma forniscono metodo personalizzato per questo.
Quindi, per quanto riguarda
ho detto che così facendo avrebbe significato che tutti i clienti che desiderano visualizzare gli oggetti avrebbero dovuto scrivere il loro proprio codice per convertire l'oggetto da stringa, ma che è stato risposto con "Sì, sarebbe".
Sono d'accordo con il vostro team leader. Se si desidera visualizzare opporsi a qualsiasi client di attuazione uso personalizzato. Se si desidera utilizzarlo per il debug scopi utilizzano toString ().
Anche se i metodi toString() sono molto utili per il debug di classi di valore, si può sostenere che sono non utile per le classi di entità .
Ho pensato di pesare con una più moderna prospettiva dato che la questione è ormai quasi 10 anni.
toString è ovviamente utile per il debug - è necessario guardare oltre tutte le altre risposte qui che attestano che -. Ma informazioni di debug non è la logica di business
Avere un metodo toString in ogni singola classe è il disordine visivo che oscura il comportamento utile della classe. Abbiamo anche bisogno di ricordarsi di mantenerlo - manualmente o rigenerando il metodo dalla nostra IDE -. Ogni volta che si cambia i campi della classe
Quindi cosa possiamo fare per affrontare questi problemi senza rimuovere il metodo del tutto? La risposta è di generare automaticamente . Progetto Lombok @ToString annotazione può generare automaticamente un metodo toString per voi a tempo di compilazione che include qualsiasi combinazione di campi che si sceglie.
Utilizzo di base del campione:
@ToString
public class Foo {
private int i = 0;
}
che diventerà equivalente al seguente al momento della compilazione:
public class Foo {
private int i = 0;
public String toString() {
return "Foo(i=" + this.i + ")";
}
}
Stiamo ottenendo un ConcurrentModificationException buttato fuori di uno dei nostri toString () metodi, quindi non c'è un inconveniente occasionale. Certo che è colpa nostra per non farcela sincronizzato.
