En ingeniería de software , un objeto Java antiguo ( POJO ) es un objeto Java ordinario , 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 estaba tan en contra del uso de objetos regulares en sus sistemas y llegamos a la conclusión de que era porque los objetos simples carecían de un nombre elegante. Así que les dimos uno y lo entendieron muy bien". [1]
El término "POJO" inicialmente denotaba un objeto Java que no sigue ninguno de los principales modelos, convenciones o marcos de objetos de Java. Desde entonces, ha sido 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 contraste con los complicados marcos de objetos. [ cita necesaria ]
El término continúa un patrón de acrónimo 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 distinta de las impuestas por la Especificación del lenguaje Java; es decir, un POJO no debería tener que hacerlo
La clase pública Foo extiende javax . servlet . http . HttpServlet { ... La clase pública Bar implementa javax . ejb . EntidadBean { ... @javax.persistence.Entity clase pública Baz { ... Sin embargo, debido a dificultades técnicas y otras razones, muchos productos o marcos de software descritos como compatibles con POJO en realidad todavía requieren el uso de anotaciones predeterminadas 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 regresara al estado de POJO si se eliminan las anotaciones, entonces aún se puede considerar 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 convierta 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 nomenclatura simple. Gracias a esta convención, se pueden hacer referencias declarativas simples a las propiedades de JavaBeans arbitrarios. El código que utiliza dicha referencia declarativa no tiene que saber nada sobre el tipo de bean, y el bean se puede usar con muchos marcos sin que estos marcos tengan que saber el tipo exacto de 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 todavía 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 la propiedad de un POJO:
<h:inputText valor= "#{MyBean.someProperty}" /> La definición del POJO puede ser la siguiente:
clase pública MyBean { cadena privada alguna propiedad ; cadena pública getSomeProperty () { return algunaProperty ; } public void setSomeProperty ( String algunaProperty ) { this . algunaPropiedad = algunaPropiedad ; } } Debido a las convenciones de nomenclatura de JavaBean, la referencia única "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)" método para establecer un valor.
A medida que los diseños que utilizan POJO se han vuelto más utilizados, han surgido sistemas que brindan a los POJO la funcionalidad completa utilizada 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 centra exclusivamente en la lógica empresarial y no depende de marcos (empresariales). Luego, los marcos de programación orientada a aspectos (AOP) agregan de forma transparente preocupaciones transversales como persistencia, transacciones, seguridad, etc. [6]
Spring fue una implementación temprana de esta idea y una de las fuerzas impulsoras detrás de la popularización de este modelo.
Un ejemplo de un bean EJB como POJO:
A continuación se muestra un bean EJB completamente funcional, que demuestra cómo EJB3 aprovecha el modelo POJO:
clase pública HolaMundoServicio { public String decirHola () { return "¡Hola mundo!" ; } } Como se indicó, 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 deben agregarse al bean:
<enterprise-beans> <sesión> <ejb-name> helloWorld </ejb-name> <ejb-class> com.example.HelloWorldService </ejb-class> <session-type> sin estado </session-type> </ sesión> </enterprise-beans> En la práctica, algunas personas encuentran que las anotaciones son elegantes, mientras que XML les parece detallado, feo y difícil de mantener, mientras que otros encuentran que las anotaciones contaminan el modelo POJO. [7]
Por lo tanto, como alternativa a XML, muchos marcos (por ejemplo, Spring, EJB y JPA) permiten el uso de anotaciones en lugar de XML o además de él. A continuación se muestra el mismo bean EJB que se muestra arriba pero con una anotación agregada. En este caso, el archivo XML ya no es necesario:
@Clase pública sin estado HelloWorldService { public String decirHola () { return "¡Hola mundo!" ; } } Con la anotación dada anteriormente, el bean ya no es un POJO verdaderamente puro, pero dado que las anotaciones son meramente 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 sigue siendo muy parecido al modelo POJO puro.
Una interfaz Java simple (POJI) es una forma básica de interfaz Java y aceptable en puntos donde no se permiten interfaces Java más complejas. [8] : 57, 572, 576, 579, 1340