1. Información general
En este breve tutorial, investigaremos la definición de "Objeto Java antiguo simple" o POJO para abreviar.
Veremos cómo se compara un POJO con un JavaBean, y cómo puede ser útil convertir nuestros POJO en JavaBeans.
2. Objetos Java antiguos sencillos
2.1. ¿Qué es un POJO ?
Cuando hablamos de un POJO, lo que estamos describiendo es un tipo sencillo sin referencias a ningún marco en particular. Un POJO no tiene una convención de nomenclatura para nuestras propiedades y métodos.
Creemos un POJO básico para empleados. Tendrá tres propiedades; nombre, apellido y fecha de inicio:
public class EmployeePojo { public String firstName; public String lastName; private LocalDate startDate; public EmployeePojo(String firstName, String lastName, LocalDate startDate) { this.firstName = firstName; this.lastName = lastName; this.startDate = startDate; } public String name() { return this.firstName + " " + this.lastName; } public LocalDate getStart() { return this.startDate; } }Esta clase puede ser utilizada por cualquier programa Java, ya que no está vinculada a ningún marco.
Pero no estamos siguiendo ninguna convención real para construir, acceder o modificar el estado de la clase.
Esta falta de convención causa dos problemas:
Primero, aumenta la curva de aprendizaje para los codificadores que intentan comprender cómo usarlo.
En segundo lugar, puede limitar la capacidad de un marco para favorecer la convención sobre la configuración, comprender cómo usar la clase y aumentar su funcionalidad.
Para explorar este segundo punto, trabajemos con EmployeePojo usando la reflexión. Por lo tanto, comenzaremos a encontrar algunas de sus limitaciones.
2.2. Reflexión con un POJO
Vamos a añadir el Commons-BeanUtils dependencia a nuestro proyecto:
commons-beanutils commons-beanutils 1.9.4 Y ahora, inspeccionemos las propiedades de nuestro POJO:
List propertyNames = PropertyUtils.getPropertyDescriptors(EmployeePojo.class).stream() .map(PropertyDescriptor::getDisplayName) .collect(Collectors.toList());Si tuviéramos que imprimir propertyNames en la consola, solo veríamos:
[start] Aquí, vemos que solo comenzamos como una propiedad de la clase. PropertyUtils no pudo encontrar los otros dos.
Veríamos el mismo tipo de resultado si usáramos otras bibliotecas como Jackson para procesar EmployeePojo.
Idealmente, veríamos todas nuestras propiedades: firstName , lastName y startDate. Y la buena noticia es que muchas bibliotecas de Java admiten de forma predeterminada algo llamado la convención de nomenclatura de JavaBean.
3. JavaBeans
3.1. ¿Qué es un JavaBean ?
Un JavaBean sigue siendo un POJO, pero introduce un conjunto estricto de reglas sobre cómo lo implementamos:
- Niveles de acceso: nuestras propiedades son privadas y exponemos getters y setters
- Nombres de métodos: nuestros captadores y definidores siguen la convención getX y setX (en el caso de un booleano, isX se puede usar para un captador)
- Constructor predeterminado: debe haber un constructor sin argumentos para que se pueda crear una instancia sin proporcionar argumentos, por ejemplo, durante la deserialización.
- Serializable: implementar la interfaz serializable nos permite almacenar el estado
3.2. EmployeePojo como JavaBean
Entonces, intentemos convertir EmployeePojo en un JavaBean:
public class EmployeeBean implements Serializable { private static final long serialVersionUID = -3760445487636086034L; private String firstName; private String lastName; private LocalDate startDate; public EmployeeBean() { } public EmployeeBean(String firstName, String lastName, LocalDate startDate) { this.firstName = firstName; this.lastName = lastName; this.startDate = startDate; } public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } // additional getters/setters }3.3. Reflexión con un JavaBean
Cuando inspeccionamos nuestro bean con reflexión, ahora obtenemos la lista completa de propiedades:
[firstName, lastName, startDate]4. Compensaciones al utilizar JavaBeans
Entonces, hemos mostrado una forma en que los JavaBeans son útiles. Tenga en cuenta que cada elección de diseño viene con compensaciones.
Cuando usamos JavaBeans también debemos tener en cuenta algunas posibles desventajas:
- Mutabilidad : nuestros JavaBeans son mutables debido a sus métodos de establecimiento; esto podría provocar problemas de concurrencia o coherencia
- Texto estándar : debemos introducir captadores para todas las propiedades y establecedores para la mayoría, gran parte de esto podría ser innecesario.
- Constructor de argumento cero : a menudo necesitamos argumentos en nuestros constructores para garantizar que el objeto se instancia en un estado válido, pero el estándar JavaBean requiere que proporcionemos un constructor de argumento cero
Dadas estas compensaciones, los marcos también se han adaptado a otras convenciones de frijoles a lo largo de los años.
5. Conclusión
En este tutorial, comparamos POJO con JavaBeans.
Primero, aprendimos que un POJO es un objeto Java que no está vinculado a un marco específico, y que un JavaBean es un tipo especial de POJO con un estricto conjunto de convenciones.
Luego, vimos cómo algunos marcos y bibliotecas aprovechan la convención de nomenclatura de JavaBean para descubrir las propiedades de una clase.
Como de costumbre, los ejemplos están disponibles en GitHub.