¿Cuándo se desea no aplicar toString () en Java?
https://stackoverflow.com/questions/1161228
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Un desarrollador principal en mi proyecto ha tomado para referirse a toString del proyecto () implementaciones como "costra pura" y está tratando de eliminarlos de la base de código.
He dicho que al hacerlo significaría que cualquier cliente que desee mostrar los objetos tendría que escribir su propio código para convertir el objeto en cadena, pero que fue respondida con un "sí lo harían".
Ahora específicamente, los objetos de este sistema son elementos gráficos como rectángulos, círculos, etc., y la representación actual es para mostrar x, y, escala, límites, etc ...
Así que, ¿de dónde viene la multitud mentira?
¿Cuándo se debe y cuando no deberías aplicar toString?
Solución
¿Qué daño hacen? ¿Por eliminarlos si los tiene? Encuentro toString () extremadamente útil al emitir declaraciones de depuración.
Personalmente, yo siempre errar en el lado de tener un método toString viable (). Tan poco trabajo para escribir.
Otros consejos
Extracción bien escrito (o incluso a mitad de camino decentemente escrito) toString () métodos es pura locura, la OMI. Sí, estoy a menudo demasiado vago para escribir éstos (como a menudo los objetos no terminan teniendo ellos utilizan de todos modos), pero son muy útiles para tener.
Realmente no puedo pensar en una buena razón para querer deshacerse de ellos.
Siempre he asegurado de que mis clases implementan toString.
Proporciona una forma sencilla de depurar el estado actual de la clase cuando estoy depuración y cuando estoy registrar errores, puedo incluirlo en mis mensajes de registro.
Me gustaría mantener las implementaciones toString(). Ellos tienen un valor incalculable cuando se trata de depurar, y que pueden hacer para una buena texto alternativo para los componentes gráficos.
Yo diría lo contrario que toString debe ser anulado juiciosamente (). La implementación por defecto toString () es muy poco informativo y básicamente inútil. Una buena aplicación toString () puede dar un desarrollador de una visión muy útil de los contenidos del objeto a simple vista. Puede que no tenga que poner todo en allí, pero al menos las cosas importantes. Creo que su desarrollador principal debe ser en realidad la codificación y la adición de características en lugar de preocuparse por "costra".
Yo sólo implementarlo para los objetos más complejos en los que el código del cliente no le interesan en los detalles de grano fino del estado del objeto, sino más bien la atención sobre algunos comprensible, haciendo sentir mensaje más humano, que resume lo que está pasando, estado sabia ...
Para todo lo demás, como JavaBeans, yo esperaría código de cliente para lanzar mi objeto en un método ToStringBuilder o similares, si es necesario realizar la depuración de bajo nivel.
ToStringBuilder.reflectionToString(myObject);
O código de cliente solo debe llamar captadores de propiedad estándar y registrar la forma que deseen ...
En general, toString() es bueno. En particular, es bastante útil para depurar .
La implementación de toString() no está exenta de costos y riesgos . Al igual que todo el código, implementaciones toString() deben mantenerse con el resto del código. Esto significa mantener toString() en sincronía con los campos de clase. Por ejemplo, cuando se añade un campo o eliminado, toString() debe ser actualizado apropiadamente (que debería estar haciendo esto ya por métodos como hashCode() y equals()).
La implementación de toString() incurre en riesgos también. Por ejemplo, supongamos que dos clases en su sistema tienen referencias a instancias de la otra (un enlace bidireccional), entonces una invocación de toString() podría dar lugar a un desbordamiento de pila debido a la recursividad ilimitada como el toString() implementación en cada clase invoca la aplicación toString() de la otra clase.
Si el sistema dispone de un número significativo de métodos toString() fuera de sincronización, o métodos que causan los insectos como los desbordamientos de pila, entonces su colega podría tener un punto razonable. Incluso en tal caso, lo haría simplemente comentar los métodos de salida con errores toString() y dejarlos en el código. Cada método toString() podría no comentada y actualizada de forma individual, según sea necesario en el futuro.
siempre auto-generar toString () métodos para todas mis POJOs, DTOs y / o cualquier objeto que contiene datos persistentes. Para las propiedades internas privadas buenas prácticas de registro debe hacer el truco.
Siempre recuerde reemplazar en toString métodos contraseñas y otra información sesitive con [Omitted] (o algo similar de la naturaleza secreta superior)
Bueno, lo que hace stramge.
No puedo decir toString () es demasiado útil. Para la presentación, necesitará otras herramientas.
Pero toString () es muy útil para la depuración, ya que podría ver el contenido de las colecciones.
No entiendo por qué quitarlo si ya está escrito
Creo que la respuesta depende de la complejidad de su toString () son métodos, la cantidad de trabajo que necesitan para mantener, y la frecuencia con que se acostumbran. Suponiendo que el uso toString () a menudo para el registro y depuración que no tiene mucho sentido para eliminar estos métodos. Pero si casi no se usan y requieren mucho trabajo para mantener cada vez que algo cambia en su código, entonces no hay tal vez un argumento válido para deshacerse de todos o algunos de los métodos toString () métodos.
Usted mencionó algo acerca de los clientes que necesitan para mostrar estos objetos. A partir de esto que estoy adivinando su código es o contiene algún tipo de biblioteca o API que utilizarán otros desarrolladores. En este caso, le recomiendo que mantenga toString (útil) implementaciones. Incluso si usted no hace un montón de registro y depuración, sus clientes pueden y van a apreciar tener toString útil () métodos que no tienen que escribir y mantener a sí mismos.
1 Mike C
Más allá de su utilidad para la depuración, el método toString () es una herramienta muy valiosa para comprender la perspectiva del autor de clase de la instancia.
Fwiw, si la salida de la toString difiere de lo que se espera ver (documentos de especificaciones de cortesía) sabrá rightaway algo salió muy mal.
En lo personal, los implemento cuando voy a utilizar objetos en un JList, JTable, u otra estructura que utiliza toString () o cuando estoy de depuración (sí, eclipse tiene formateadores de depuración, pero toString () es más fácil) .
Tal vez se puede devolver el fuego que muchas clases de JDK tienen toString (). Deben ser eliminados así? ;)
Yo diría que se debe implementar toString si eso es un caso de uso esperado o requisito, para mostrar el objeto como una representación de cadena (ya sea en los registros, en la consola, o una especie de árbol de la pantalla).
Por lo demás, estoy de acuerdo con el desarrollador - cada vez que cambie algo, el toString puede romper. Puede que tenga que tener cuidado con los nulos, etc.
Muchas veces, sin embargo, es de hecho se utiliza en la depuración o en el registro, por lo que no es obvio que se deben dejar en absoluto.
Estoy de acuerdo con jsight que si ya están escritos, y se escriben con decencia, dejarlos en por lo menos hasta que se interpongan en el camino (como en realidad se agrega un campo a una clase).
Para propósitos de depuración, nadie puede vencer a toString. Es práctico, tanto en un depurador, y en grabados sencillas de depuración. Asegúrese de que muestra todos los campos que sus métodos equals y hashCode se basan en, si reemplaza esos también!
Para la visualización a los usuarios finales, yo no utilizar toString, sin embargo. Por eso, creo que es mejor escribir otro método, que hace el formato correcto, y i18n si necesita eso.
Es de sentido común, ya que siempre tiene problemas con toStrings muestra información demasiado poco o demasiado.
Puede tener sentido para su equipo para utilizar el ToStringBuilder en Jakarta Commons Lang en su lugar:
System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
cuales introspección del objeto, e imprime los campos públicos.
He dicho que al hacerlo significaría que cualquier cliente que desee mostrar los objetos tendrían que escribir su el propio código para convertir el objeto a cadena, pero que fue respondida con "Sí que lo harían".
Esto no es una pregunta que se pueda responder de manera aislada ... usted debe preguntar a los clientes (o las personas que escriben ellos) lo que piensan de la idea. Si yo estaba usando una biblioteca de Java y confiando en su toString () sobrecargas para la depuración, estaría bastante molesto si los desarrolladores de la biblioteca decidieron afinará.
Para ser justos, dicho revelador aquí, pero no conduce desarrollador en ningún sentido.
El tema original no se trata necesariamente de toString (), pero alrededor de un segundo paramString método: "Con toda su concatenación de cadenas y la comprobación de valor nulo, paramString es un imán de errores."
http://code.google.com/p/ Piccolo2D / temas / detalle? id = 99
Sin duda, mantener el toString () implementaciones, sobre todo para fines de depuración. Como desarrollador principalmente C ++, me gustaría que las cosas eran tan fáciles en C ++, ya que son en Java a este respecto (sobrecarga de operadores puede ser un dolor).
Si hay un problema con las implementaciones existentes toString(), el desarrollador debe solucionar el problema. Diciendo que las implementaciones actuales son todos "costra pura" y la eliminación de ellos está haciendo activamente daño, a menos que los métodos existentes son toString() poco común mal escrito.
Me muy desalentar el desarrollador de la eliminación de cualquier método toString() funcionamiento.
implementar siempre :) Como se mencionó anteriormente, es muy valiosa para la depuración.
Es bueno para fines de depuración. Pero si desea mostrar objeto dado como una cadena para el usuario final nunca se debe utilizar toString aplicación () pero proporcionan método personalizado para eso.
Así que con respecto
He dicho que al hacerlo significaría que cualquier cliente que desee mostrar los objetos tendrían que escribir su el propio código para convertir el objeto a cadena, pero que fue respondida con "Sí que lo harían".
Estoy de acuerdo con su jefe de equipo. Si desea mostrar objeto a cualquier aplicación cliente de uso personalizado. Si desea utilizarlo para propósitos de depuración utilizan toString ().
Aunque los métodos toString() son muy útiles para la depuración de las clases de valor, se puede argumentar que son no es útil para las clases de entidad .
pensé que había que pesan con una perspectiva más moderna, dado que esta pregunta es ahora casi 10 años.
toString es obviamente útil para la depuración - es necesario mirar más allá de todas las otras respuestas aquí, que dan fe de que -. Pero información de depuración no es la lógica de negocio
Tener un método toString en cada clase individual es el desorden visual que oscurece el comportamiento útil de la clase. También tenemos que recordar para mantenerla - ya sea manualmente o mediante la regeneración del método de nuestra IDE -. cada vez que cambie los campos de marcas
Entonces, ¿qué podemos hacer para hacer frente a estos problemas sin necesidad de retirar el método en total? La respuesta es generar automáticamente . del Proyecto Lombok @ToString anotación puede generar automáticamente un método toString para usted en tiempo de compilación que incluye cualquier combinación de campos que elija.
ejemplos de uso básica:
@ToString
public class Foo {
private int i = 0;
}
¿Qué se convertirá equivalente a la siguiente en tiempo de compilación:
public class Foo {
private int i = 0;
public String toString() {
return "Foo(i=" + this.i + ")";
}
}
Estamos recibiendo un ConcurrentModificationException expulsado de una de nuestras toString () métodos, por lo que hay un inconveniente ocasional. Por supuesto que es nuestra culpa por no lo que es sincronizado.
