¿Cuáles son las reglas correctas para escribir una clase JavaBean?Reglas de clase JavaBean
Estoy confundido porque algunos libros usan necesidad, mientras que otros usuarios deberían o podrían describir la regla de escritura:
decir
Un JavaBean se define por su propiedades (es decir, sus métodos get y set), no es campos. Aunque los términos se usan de manera intercambiable, eso en realidad no es correcto. El mecanismo Introspector ignora los campos por completo.
Ejemplo
Tome este Javabean (terriblemente diseñada):
public class TestBean {
private int baz;
private char[] phleem;
public String getFoo() {
return new String(phleem);
}
public void setFoo(final String foo) {
this.phleem = foo.toCharArray();
}
public long getBar() {
return baz;
}
public void setBar(final long bar) {
this.baz = (int) bar;
}
}
Uno pensaría que las propiedades son:
int)char[])pero ahora vamos a inspeccionar con la Javabeans introspector:
for (PropertyDescriptor descriptor : Introspector
.getBeanInfo(TestBean.class, Object.class)
.getPropertyDescriptors()) {
System.out.println("Name: " + descriptor.getName() +
", type: " + descriptor.getPropertyType());
}
Aquí está la salida:
Name: bar, type: long
Name: foo, type: class java.lang.String
Conclusión:
getters y setters son las que definen una propiedad Javabeans . Es una convención que están respaldados por campos del mismo nombre y tipo, pero los campos no son realmente parte de las propiedades de Javabean (aunque muchas documentaciones sugerirán lo contrario).
Al volver a leer mi respuesta: se trata de una adición a las otras respuestas. Si quieres una respuesta corta y simple, ve con skaffman's.
Añadiendo al poster anterior - skaffman. Siempre es una buena práctica anular, toString(), hashCode(), equals() y finalmente escribir un constructor sobrecargado que tenga todos los campos (que esta clase tiene) como entrada.
Asegúrese de no utilizar otras referencias (como List, HashMaps, etc.) en la implementación de toString() y hashCode().
En una nota lateral, Eclipse tiene una funcionalidad integrada para generarlos para usted ..
Es una clase pública.
Tiene un constructor sin parámetros pública (aunque puede tener otros constructores también)
Se implementa la interfaz Serializable (es decir, puede hacerse persistente, por lo que su estado puede se guardará)
tiene propiedades con métodos “setter” nombrados siguiendo JavaBeans patrones de nombres
tiene eventos que siguen el estándar Jav “captador” y un modelo de evento con el registro métodos nombrados siguiendo los patrones de nombres JavaBeans
Puede tener otros métodos que no sigan los patrones de nomenclatura. Estos métodos no están expuestos por una herramienta de construcción.
Todo lo anterior y no debe cruzar los límites de la API de Java. Significa que no debe extender o implementar ninguna clase o interfaz, pero una relajación es que puede implementar una sola interfase serializable porque es una interfaz de marcador
Lo siento pero no entiendo bien. Si no hay una coincidencia obligatoria entre un nombre de variable y un nombre de método get/set, ¿cómo puede una herramienta de compilación obtener o establecer esa variable, es decir, su nombre? – xdevel2000
@ xdevel2000: Porque esa "falta de coincidencia" está definida por la especificación javaBean, como una convención de nomenclatura. – skaffman
Como dije: es una convención, nada más. En el 99% de los casos, debe usar esta convención y las herramientas le ayudarán * solo * si usa esta convención. Pero solo quería informarle que los campos subyacentes * no son * propiedades de beans, mientras que los métodos getter y setter sí lo son. –