En ingeniería de software , un objeto Java común y corriente ( POJO ) es un objeto Java común y corriente , que no está sujeto a ninguna restricción especial. El término fue acuñado por Martin Fowler , Rebecca Parsons y Josh MacKenzie en septiembre de 2000: [1]
"Nos preguntamos por qué la gente se oponía tanto a utilizar objetos comunes en sus sistemas y concluimos que era porque los objetos simples no tenían un nombre elegante. Así que les dimos uno y se puso de moda muy bien". [1]
El término "POJO" inicialmente denotaba un objeto Java que no seguía ninguno de los principales modelos, convenciones o marcos de objetos de Java. Desde entonces, se ha adoptado como un término independiente del lenguaje, debido a la necesidad de un término común y de fácil comprensión que contrastara con los marcos de objetos complicados. [ cita requerida ]
El término continúa un patrón de acrónimos para acuñar retrónimos para construcciones que no utilizan características nuevas y sofisticadas:
Idealmente hablando, un POJO es un objeto Java que no está sujeto a ninguna restricción más allá de las impuestas por la Especificación del Lenguaje Java; es decir, un POJO no debería tener que
clase pública Foo extiende javax . servlet . http . HttpServlet { ... La clase pública Bar implementa javax . ejb . EntityBean { ... @javax.persistence.Entity clase pública Baz { ... Sin embargo, debido a dificultades técnicas y otras razones, muchos productos de software o marcos de trabajo descritos como compatibles con POJO en realidad aún requieren el uso de anotaciones preestablecidas para que funciones como la persistencia funcionen correctamente. La idea es que si el objeto (en realidad, la clase) fuera un POJO antes de que se agregaran las anotaciones y volviera al estado de POJO si se eliminan las anotaciones, entonces aún puede considerarse un POJO. Entonces, el objeto básico sigue siendo un POJO en el sentido de que no tiene características especiales (como una interfaz implementada) que lo conviertan en un "Objeto Java especializado" (SJO o (sic) SoJO).
Un JavaBean es un POJO que es serializable , tiene un constructor sin argumentos y permite el acceso a propiedades mediante métodos getter y setter que siguen una convención de nombres simple. Debido a esta convención, se pueden hacer referencias declarativas simples a las propiedades de JavaBeans arbitrarios. El código que usa una referencia declarativa de este tipo no tiene que saber nada sobre el tipo del bean, y el bean se puede usar con muchos marcos sin que estos marcos tengan que saber el tipo exacto del bean. La especificación JavaBeans, si se implementa completamente, rompe ligeramente el modelo POJO ya que la clase debe implementar la interfaz Serializable para ser un verdadero JavaBean. Muchas clases POJO que aún se llaman JavaBeans no cumplen con este requisito. Dado que Serializable es una interfaz de marcador (sin método), esto no es una gran carga.
A continuación se muestra un ejemplo de un componente JavaServer Faces (JSF) que tiene un enlace bidireccional a una propiedad POJO:
<h:inputText valor= "#{MyBean.someProperty}" /> La definición del POJO puede ser la siguiente:
clase pública MyBean { cadena privada algunaPropiedad ; public String obtenerAlgunaPropiedad () { devolver algunaPropiedad ; } public void setSomeProperty ( String someProperty ) { this . someProperty = someProperty ; } } Debido a las convenciones de nombres de JavaBean, la única referencia "someProperty" se puede traducir automáticamente al método "getSomeProperty()" (o "isSomeProperty()" si la propiedad es de tipo booleano ) para obtener un valor, y al método "setSomeProperty(String)" para establecer un valor.
La biblioteca lombok permite cambiar el código dinámicamente para integrar esas convenciones sin la molestia de escribirlas. El siguiente código generaría el mismo bean, con el agregado de un constructor vacío:
@NoArgsConstructor clase pública MyBean { @Getter @Setter cadena privada algunaPropiedad ; }Otras bibliotecas o frameworks generan código (o bytecode) con esas convenciones directamente. La incorporación de esas herramientas ayuda a aliviar el código repetitivo , lo que a su vez reduce la frecuencia de errores y el costo de mantenimiento.
A medida que los diseños que utilizan POJO se han vuelto más comunes, han surgido sistemas que les otorgan a los POJO la funcionalidad completa que se usa en los marcos y más opciones sobre qué áreas de funcionalidad son realmente necesarias. En este modelo, el programador no crea nada más que un POJO. Este POJO se enfoca puramente en la lógica empresarial y no tiene dependencias en los marcos (empresariales). Los marcos de programación orientada a aspectos (AOP) luego agregan de manera transparente preocupaciones transversales como persistencia, transacciones, seguridad, etc. [6]
Spring fue una de las primeras implementaciones de esta idea y una de las fuerzas impulsoras detrás de la popularización de este modelo.
Un ejemplo de un bean EJB que es un POJO:
A continuación se muestra un bean EJB completamente funcional, que demuestra cómo EJB3 aprovecha el modelo POJO:
clase pública HelloWorldService { public String sayHello () { return "¡Hola, mundo!" ; } } Como se indica, el bean no necesita extender ninguna clase EJB ni implementar ninguna interfaz EJB y tampoco necesita contener ninguna anotación EJB. En cambio, el programador declara en un archivo XML externo qué servicios EJB se deben agregar al bean:
<enterprise-beans> <sesión> <nombre-ejb> helloWorld </nombre-ejb> <clase-ejb> com.example.HelloWorldService </clase-ejb> <tipo- sesión> sin estado </ tipo-sesión > </sesión > </enterprise-beans> En la práctica, algunas personas consideran que las anotaciones son elegantes, mientras que consideran que XML es verboso, feo y difícil de mantener, mientras que otras consideran que las anotaciones contaminan el modelo POJO. [7]
Por lo tanto, como alternativa a XML, muchos frameworks (por ejemplo, Spring, EJB y JPA) permiten utilizar anotaciones en lugar de XML o además de este. A continuación se muestra el mismo bean EJB que se muestra arriba, pero con una anotación añadida. En este caso, ya no se necesita el archivo XML:
@Stateless clase pública HelloWorldService { public String sayHello () { return "¡Hola, mundo!" ; } } Con la anotación dada arriba, el bean ya no es un POJO puro, pero como las anotaciones son simplemente metadatos pasivos, esto tiene muchos menos inconvenientes dañinos en comparación con la invasividad de tener que extender clases y/o implementar interfaces. [6] En consecuencia, el modelo de programación todavía es muy parecido al modelo POJO puro.
Una interfaz Java simple (POJI) es una forma básica de interfaz Java y es aceptable en puntos donde no se permiten interfaces Java más complejas. [8] : 57, 572, 576, 579, 1340