Hispanopedia WikiEn ingeniería de software , un objeto Java simple ( 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 preguntábamos por qué la gente se oponía tanto al uso de objetos comunes en sus sistemas y llegamos a la conclusión de que era porque a los objetos simples les faltaba un nombre llamativo. Así que les dimos uno, y ha tenido una gran acogida.
El término "POJO" inicialmente designaba un objeto Java que no seguía ninguno de los principales modelos, convenciones o marcos de trabajo de Java. Posteriormente, se ha popularizado como término independiente del lenguaje, debido a la necesidad de un término común y fácil de entender que contrastara con los complejos marcos de trabajo de objetos.
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:
- "Objeto JavaScript simple y antiguo" en JavaScript [ 2 ]
- "Objeto Ruby simple y antiguo" (PORO) en Ruby
- "Documentación simple y antigua" (pod) en Perl
- Objeto CLR simple (POCO) [ 3 ] en el .NET Framework
- "Objeto PHP simple y antiguo" (POPO) [ 4 ] [ 5 ] en PHP
- Servicio telefónico básico (POTS) en telefonía
Definición
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:
- Extienda las clases preespecificadas, como en
import javax.servlet.http.HttpServlet ;public class Foo extends HttpServlet { // ... }- Implementar interfaces preespecificadas, como en
import javax.ejb.EntityBean ;public class Bar implements EntityBean { // ... }- Contiene anotaciones preespecificadas , como en
import javax.persistence.Entity ;@Entity public class Baz { // ... }Sin embargo, debido a dificultades técnicas y otras razones, muchos productos o marcos de software descritos como compatibles con POJO aún requieren el uso de anotaciones predefinidas para que ciertas características, como la persistencia, funcionen correctamente. La idea es que si el objeto (o clase) era un POJO antes de agregarle cualquier anotación, y recuperaría su estado de POJO al eliminarlas, entonces aún puede considerarse un POJO. En ese caso, el objeto básico sigue siendo un POJO, ya que no posee características especiales (como una interfaz implementada) que lo conviertan en un "Objeto Java Especializado" (SJO o SoJO).
Variaciones contextuales
JavaBeans
Un JavaBean es un POJO serializable , con un constructor sin argumentos y que permite acceder a sus propiedades mediante métodos getter y setter que siguen una convención de nomenclatura sencilla. Gracias a esta convención, se pueden crear referencias declarativas simples a las propiedades de cualquier JavaBean. El código que utiliza dicha referencia declarativa no necesita conocer el tipo del bean, y este puede utilizarse con diversos frameworks sin que estos deban conocer su tipo exacto. La especificación JavaBeans, si se implementa por completo, modifica ligeramente el modelo POJO, ya que la clase debe implementar la interfaz Serializable para ser un JavaBean auténtico. Muchas clases POJO que aún se denominan JavaBeans no cumplen este requisito. Dado que Serializable es una interfaz de marcador (sin métodos), esto no supone una gran desventaja.
A continuación se muestra un ejemplo de un componente JavaServer Faces (JSF) que tiene un enlace bidireccional a una propiedad de un POJO:
<h:inputText value= "#{MyBean.someProperty}" />La definición de POJO puede ser la siguiente:
clase pública MyBean { cadena privada algunaPropiedad ;public String getSomeProperty () { return someProperty ; }public void setSomeProperty ( String someProperty ) { this . someProperty = someProperty ; } }Debido a las convenciones de nomenclatura de JavaBean, la única somePropertyreferencia " " se puede traducir automáticamente al método " getSomeProperty()" (o " isSomeProperty()" si la propiedad es de tipo booleano ) para obtener un valor, y al setSomeProperty(String)método " " para establecer un valor.
La biblioteca Project Lombok permite modificar el código dinámicamente para integrar dichas convenciones sin la molestia de tener que escribirlas manualmente. El siguiente código generaría el mismo bean, con la adición de un constructor vacío:
@NoArgsConstructor public class MyBean { @Getter @Setter private String someProperty ; }Otras bibliotecas o frameworks generan código (o bytecode) con esas convenciones directamente. La incorporación de estas herramientas ayuda a reducir el código repetitivo , lo que a su vez disminuye la frecuencia de errores y el costo de mantenimiento.
Agregar servicios de forma transparente
A medida que los diseños que utilizan POJO se han vuelto más comunes, han surgido sistemas que les brindan a los POJO la funcionalidad completa de los frameworks y mayor libertad para elegir qué áreas de funcionalidad son realmente necesarias. En este modelo, el programador crea simplemente un POJO. Este POJO se centra exclusivamente en la lógica de negocio y no tiene dependencias de frameworks (empresariales). Los frameworks de programación orientada a aspectos (AOP) agregan de forma transparente aspectos transversales como la persistencia, las transacciones, la seguridad, etc. [ 6 ]
Spring fue una de las primeras aplicaciones de esta idea y uno de los principales impulsores 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 dependencias para la plataforma Java EE)
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!" ; } }Por definición, el bean no necesita extender ninguna clase EJB ni implementar ninguna interfaz EJB, ni tampoco necesita contener ninguna anotación EJB. En su lugar, el programador declara en un archivo XML externo qué servicios EJB deben agregarse al bean:
<enterprise-beans> <session> <ejb-name> helloWorld </ejb-name> <ejb-class> com.example.HelloWorldService </ejb-class> <session-type> stateless </session-type> </session> </enterprise-beans>En la práctica, algunas personas encuentran las anotaciones elegantes, mientras que ven XML como verboso, feo y difícil de mantener, mientras que otras consideran que las anotaciones contaminan el modelo POJO. [ 7 ]
Así, como alternativa a XML, muchos frameworks (por ejemplo, Spring, EJB y JPA) permiten usar anotaciones en lugar de XML o además de él. A continuación se muestra el mismo bean EJB que el anterior, pero con una anotación añadida. 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 puro, pero dado que las anotaciones son simplemente metadatos pasivos, esto tiene muchos menos inconvenientes perjudiciales en comparación con la invasividad de tener que extender clases o implementar interfaces. [ 6 ] Por consiguiente, el modelo de programación sigue siendo muy similar al modelo POJO puro.
Acrónimos relacionados
Interfaz Java simple y antigua
Una interfaz Java simple (POJI) es una forma básica de interfaz Java y es aceptable en los casos en que no se permiten interfaces Java más complejas. [ 8 ] : 57, 572, 576, 579, 1340
Véase también
Referencias
- ↑ «MF Bliki: POJO» . MartinFowler.com .
- ↑ Almaer, Dion (17 de julio de 2006). "El regreso del POJO: JavaScript simple y viejo" . Ajaxian . Archivado del original el 13 de septiembre de 2014. Recuperado el 19 de agosto de 2014 .
- ↑ "Soporte para POCO" . microsoft.com . Consultado el 27 de mayo de 2012 .
- ↑ Kneschke, Jan (19 de febrero de 2007). "Objetos con tipado seguro en PHP" . kneschke.de . Archivado del original el 26 de marzo de 2012. Consultado el 27 de mayo de 2012 .
- ↑ Cheong, Jym (26-06-2011). "Controlador con objeto PHP simple básico, también conocido como POPO" . jym.sg. Archivado del original el 26-03-2012 . Recuperado el 27-05-2012 .
- 1 2 Martin, Robert C; (2008); Código limpio , Capítulo 11, Marcos de trabajo 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 despliegue frente a anotaciones
- ↑ Wahli, Ueli; Vieira, Miguel; Gomes, Ferreira Lopes; Hainey, Brian; Moharram, Ahmed; Nápoles, JuanPablo; Rohr, Marco; Cui, Henry; Gan, Patricio; González, Celso; Ugurlu, Pinar; Ziosi, Lara (29 de junio de 2009). Guía de programación de Rational Application Developer V7.5 . Libros rojos de IBM. ISBN 978-0738432892.
