En ingeniería de software , un objeto Java simple y antiguo ( POJO ) es un objeto Java ordinario , no 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 se debía a que los objetos simples no tenían un nombre elegante. Así que les dimos uno y se entendió muy bien". [1]
El término "POJO" denotaba inicialmente un objeto Java que no sigue ninguno de los principales modelos, convenciones o marcos de objetos Java; hoy en día "POJO" también se puede utilizar como acrónimo de un objeto JavaScript antiguo , en cuyo caso el término denota un objeto JavaScript de pedigrí similar. [2]
El término sigue un patrón de acrónimo para acuñar retrónimos de tecnologías que no utilizan nuevas características sofisticadas: objeto Ruby antiguo simple (PORO) en Ruby , servicio telefónico antiguo simple (POTS) en telefonía y Documentación antigua simple (pod) en Perl . El equivalente a POJO en .NET Framework es un objeto CLR antiguo simple (POCO). [3] Para PHP , es un simple objeto PHP antiguo (POPO). [4] [5]
Es muy probable que el fenómeno POJO haya ganado una aceptación generalizada debido a la necesidad de un término común y fácil de entender que contrasta con los marcos de objetos complicados. [ cita requerida ]
Definición
Idealmente hablando, un POJO es un objeto Java que no está sujeto a ninguna restricción que no sea la impuesta por la Especificación del lenguaje Java; es decir, un POJO no debería tener que
- Amplíe las clases preespecificadas, como en
La clase pública Foo extiende javax . servlet . http . HttpServlet { ...
- Implementar interfaces preespecificadas, como en
public class Bar implementa javax . ejb . EntityBean { ...
- Contienen anotaciones preespecificadas , como en
@ javax.persistence.Entity public class Baz { ...
Sin embargo, debido a dificultades técnicas y otras razones, muchos productos de software o marcos descritos como compatibles con POJO todavía requieren el uso de anotaciones preespecificadas para que características 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 volvería al estado de POJO si se eliminan las anotaciones, todavía 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 convierte en un "Objeto Java especializado" (SJO o (sic) SoJO).
Variaciones contextuales
JavaBeans
Un JavaBean es un POJO que es serializable , tiene un constructor sin argumentos y permite el acceso a propiedades usando métodos getter y setter que siguen una convención de nomenclatura 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 de bean, y el bean se puede usar con muchos marcos sin que estos marcos tengan que conocer 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 de POJO todavía llamadas 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:
value = "# {MyBean.someProperty}" />
La definición del POJO puede ser la siguiente:
public class MyBean { Private String someProperty ; public String getSomeProperty () { devolver algunaProperty ; } public void setSomeProperty ( String someProperty ) { esto . 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.
Agregar servicios de forma transparente
A medida que los diseños que utilizan POJO se han vuelto más comúnmente 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 crea nada más que un POJO. Este POJO se centra exclusivamente en la lógica empresarial y no depende de 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 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 que es un POJO:
- Enterprise JavaBeans (EJB),
- API de persistencia de Java (JPA) (incluido Hibernate )
- CDI (Contextos e inyección de dependencia para la plataforma Java EE)
A continuación, se muestra un bean EJB completamente funcional, que demuestra cómo EJB3 aprovecha el modelo POJO:
public class HelloWorldService { public String sayHello () { return "¡Hola, mundo!" ; } }
Como se indica, el bean no necesita extender ninguna clase EJB o implementar ninguna interfaz EJB y tampoco necesita contener anotaciones EJB. En cambio, el programador declara en un archivo XML externo qué servicios EJB deben agregarse al bean:
helloWorld com.example.HelloWorldService stateless
En la práctica, algunas personas encuentran que las anotaciones son elegantes, mientras que ven XML como detallado, feo y difícil de mantener, mientras que otras 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 que las anotaciones se utilicen en lugar de o además de XML. 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:
@Stateless public class HelloWorldService { public String sayHello () { 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.
Siglas relacionadas
Interfaz Java simple y antigua
Una interfaz Java simple y antigua (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
Ver también
Referencias
- ^ a b "MF Bliki: POJO" . MartinFowler.com .
- ^ Almaer, Dion (17 de julio de 2006). "Retorno del POJO: Plain 'Ole JavaScript" . Ajaxian . Consultado el 19 de agosto de 2014 .
- ^ "Soporte POCO" . microsoft.com . Consultado el 27 de mayo de 2012 .
- ^ Kneschke, enero (19 de febrero de 2007). "objetos de tipo seguro en PHP" . kneschke.de . Archivado desde el original el 26 de marzo de 2012 . Consultado el 27 de mayo de 2012 .
- ^ Cheong, Jym (26 de junio de 2011). "Controlador con objeto PHP simple y simple, también conocido como POPO" . jym.sg . Archivado desde el original el 26 de marzo de 2012 . Consultado el 27 de mayo de 2012 .
- ↑ a b Martin, Robert C; (2008); Código limpio , capítulo 11, marcos de AOP de Java puro
- ^ Panda, Debu; Rahman, Reza; Lane, Derek; (2007). EJB 3 en acción , Manning Publications Co., Shelter Island (NY), ISBN 978-1-93-398834-4 (www.manning.com/books/ejb-3-in-action). Capítulo 11, Descriptores de implementación frente a anotaciones
- ^ Wahli, Ueli; Vieira, Miguel; Gomes, Ferreira Lopes; Hainey, Brian; Moharram, Ahmed; Nápoles, JuanPablo; Rohr, Marco; Cui, Henry; Gan, Patrick; González, Celso; Ugurlu, Pinar; Ziosi, Lara (29 de junio de 2009). Guía de programación de Rational Application Developer V7.5 . IBM Redbooks. ISBN 978-0738432892.