2011-10-01 22 views
14

Quería saber si alguien sabe acerca de una buena manera de actualizar, constructores, iguales, hash, a la cadena, etc. generados por eclipse en Java. Mucho tiempo, después de utilizar los códigos de barras generados automáticamente, agrego una variable miembro a la clase, y luego necesito eliminar el código generado automáticamente, y hacerlo todo de nuevo. ¿Hay alguna manera de provocar que eclipse agregue la nueva variable a los códigos-stubs autogenerados?cómo actualizar los constructores de Java, iguales, hash, etc. en eclipse?

editar: ok eliminar no es esencial, sin embargo, todavía tengo que ir y generar cada uno de ellos, estoy buscando una solución automática.

+0

Creo que es mucho más importante tenerlo correcto que generado automáticamente. La respuesta de Apache HashCode es el camino a seguir. – JohnKlehm

Respuesta

4

Tome una mirada en www.projectlombok.org como una alternativa a escribir estos métodos usted mismo. En particular, la anotación @Data parece ajustarse a su necesidad, consulte http://www.projectlombok.org/features/Data.html.

+0

Esto es bueno. pero tiene un inconveniente. cuando hace referencia a conjuntos, obtiene, etc. de otra clase, eclipse no sabrá cómo autocompletar (usando CTRL + SPACE) porque estos métodos se generan sobre la marcha ... – stdcall

+1

En realidad, la autocompleta también funciona, verifique los documentos. – Kevin

+0

interesante, lo verificare – stdcall

2

Iv'e creó un proyecto propio con un campo y pidió eclipse para generar todos los métodos de base. Después de eso agregué un nuevo campo, le pedí que generara estos métodos de nuevo (fuente -> generar ...), me incitó a reemplazar los antiguos, hice clic en 'sí' y se mostraron los métodos actualizados.

espero que ayudó

+0

No fue así. Quiero que se actualice automáticamente o con un botón. como dijiste, tengo que hacerlo todo de nuevo para todos los stubs – stdcall

6

Esto no es exactamente una solución a su pregunta, pero ya no utilizan los métodos generados automáticamente Eclipse, yo uso el Apache commons langEqualsBuilder y HashCodeBuilder:

Así, por ejemplo, usted puede hacer:

import org.apache.commons.lang3.builder.EqualsBuilder; 
import org.apache.commons.lang3.builder.HashCodeBuilder; 
import org.apache.commons.lang3.builder.ReflectionToStringBuilder; 

public class EqualsTest { 
    private String foo; 
    private int bar; 

    // getters and setters 

    @Override 
    public String toString() { 
     return ReflectionToStringBuilder.toString(this); 
    } 

    @Override 
    public int hashCode() { 
     return HashCodeBuilder.reflectionHashCode(this); 
    } 

    @Override 
    public boolean equals(Object obj) { 
     return EqualsBuilder.reflectionEquals(this, obj); 
    } 
} 

Esto utiliza la reflexión, y no necesita cambiar cuando agrega un campo. Sin embargo, hay otras opciones en las que puede especificar los campos que se usarán y si también desea tener en cuenta el hashCode de la superclase.

EDITAR: Como se ha señalado, el aspecto de reflexión de esto puede tener algunas penalizaciones de rendimiento asociadas. Personalmente, no uso el reflejo HashCodeBuilder o EqualsBuilder en el código de producción, utilizo el toHashCode (como se muestra a continuación). Sin embargo, utilizo ReflectionToStringBuilder para el registro y cosas por el estilo.

Este es un ejemplo que no utiliza la reflexión, pero se requiere añadir otra línea cuando se agrega un campo:

public int hashCode() { 
    // you pick a hard-coded, randomly chosen, non-zero, odd number 
    // ideally different for each class 
    return new HashCodeBuilder(17, 37). 
    append(foo). 
    append(bar). 
    toHashCode(); 
} 

Para mayor discusión sobre hashCodeBuilder, ver apache commons equals/hashcode builder

+0

Yowzers, apuesto * que es * performant! :) –

+0

Bueno, si buscas objetos inmutables, que suelo intentar hacer, puedes guardar en caché los valores de toString y hashCode que te ayudarían mucho. – ArtB

+0

@Ernest No está mal en realidad, depende de lo que estés haciendo. Las ventajas de no tener que generar su propio hashCode() y usar un hashCode estándar, y sobre todo, corregir, superan cualquier problema menor de rendimiento. –

Cuestiones relacionadas