entre - ¿Qué significa exactamente el término antiguo objeto Java plano(POJO)?
pojo java example (8)
¿Qué significa el término Objeto simple de Java (POJO) ? No pude encontrar nada lo suficientemente explicativo.
La página de Wikipedia de POJO dice que POJO es un objeto común de Java y no un objeto especial. Ahora, ¿qué hace o qué no hace y objeto especial en Java?
La página anterior también dice que un POJO no debería tener que extender clases preespecificadas, implementar Interfaces preespecificadas o contener Anotaciones preespecificadas. ¿Eso también significa que los POJO no pueden implementar interfaces como Serializable , Comparable o clases como Applets o cualquier otra Clase / Interfaz escrita por el usuario?
Además, ¿la política anterior (sin extensión, sin implementación) significa que no se nos permite usar ninguna biblioteca externa?
¿Dónde se usan exactamente los POJO?
EDITAR: Para ser más específico, ¿puedo extender / implementar clases / interfaces que son parte de Java o de cualquier biblioteca externa?
¿Qué significa el término Objeto simple de Java (POJO)?
POJO fue creado por Martin Fowler, Rebecca Parsons y Josh Mackenzie cuando se preparaban para una conferencia en una conferencia en septiembre de 2000. Martin Fowler en Patterns of Enterprise Application Architecture explica cómo implementar un patrón de modelo de dominio en Java. Después de enumerar algunas de las desventajas de usar EJB Entity Beans :
Siempre se genera mucho calor cuando las personas hablan sobre el desarrollo de un Modelo de Dominio en J2EE. Muchos de los materiales de enseñanza y libros introductorios de J2EE sugieren que se usen beans de entidad para desarrollar un modelo de dominio, pero existen algunos problemas serios con este enfoque, al menos con la especificación actual (2.0).
Los beans de entidad son más útiles cuando usa Container Managed Persistence (CMP) ...
Los beans de entidad no pueden ser reentrantes. Es decir, si llama desde un bean de entidad a otro objeto, ese otro objeto (o cualquier objeto al que llama) no puede volver a llamar al primer bean de entidad ...
... Si tienes objetos remotos con interfaces finas, obtienes un rendimiento terrible ...
Para ejecutar con beans de entidad necesita un contenedor y una base de datos conectados. Esto aumentará los tiempos de construcción y también aumentará el tiempo para realizar pruebas ya que las pruebas se deben ejecutar en una base de datos. Los beans de entidad también son difíciles de depurar.
Como alternativa, propuso utilizar Objetos de Java Regulares para la implementación del Modelo de Dominio:
La alternativa es usar objetos normales de Java, aunque esto a menudo causa una reacción de sorpresa: es sorprendente cuánta gente piensa que no se pueden ejecutar objetos Java normales en un contenedor EJB. Llegué a la conclusión de que la gente se olvida de los objetos normales de Java porque no tienen un nombre elegante. Es por eso que, mientras me preparaba para una charla en 2000, Rebecca Parsons, Josh Mackenzie y yo les dimos uno: POJOs (simples objetos antiguos de Java) . Un modelo de dominio POJO es fácil de armar, es rápido de construir, puede ejecutarse y probarse fuera de un contenedor EJB, y es independiente de EJB (tal vez por eso los proveedores de EJB no lo alientan a usarlo).
El objetivo de un POJO es la simplicidad y pareces estar asumiendo que es algo más complicado de lo que parece.
Si una biblioteca admite un POJO, implica que un objeto de cualquier clase es aceptable. No significa que el POJO no puede tener anotaciones / interfaz o que no se usarán si están allí, pero no es un requisito.
En mi humilde opinión, la página wiki es bastante clara. No dice que un POJO no puede tener anotaciones / interfaces.
El uso del término implica lo que se supone que debe decirte. Si, por ejemplo, un marco de inyección de dependencia le dice que puede inyectar un POJO en otro POJO, quiere decir que no tiene que hacer nada especial: no hay necesidad de obedecer ningún contrato con su objeto, implementar ninguna interfaz o extender clases especiales. Puedes usar lo que ya tienes.
ACTUALIZAR Para dar otro ejemplo: mientras Hibernate puede mapear cualquier POJO (cualquier objeto que haya creado) a tablas SQL, en Core Data (Objetivo C en el iPhone) sus objetos tienen que extender NSManagedObject para que el sistema pueda persistir en ellos. una base de datos En ese sentido, Core Data no puede funcionar con ningún POJO (o más bien POOCO = PlainOldObjectiveCObject) mientras que Hibernate puede hacerlo. (Es posible que no haya corregido al 100% los datos básicos ya que empecé a buscarlos. Cualquier sugerencia / corrección es bienvenida :-)).
POJO es un Objeto simple de Java simple, en comparación con algo que necesita material de Enterprise Edition (J2EE) (frijoles, etc.).
POJO no es realmente una definición difícil y rápida, y más una forma ondulada a mano de describir objetos Java no empresariales "normales". Si el uso de una biblioteca o marco externo hace que un objeto sea o no POJO es algo que está en el ojo del espectador, que depende en gran medida de QUÉ biblioteca / marco, aunque me aventuraría a adivinar que un marco haría de POJO algo menos
Plain Old Java Objeto :)
Bueno, lo haces sonar como esas son todas las restricciones terribles.
En el contexto habitual en el que se utiliza POJO, se parece más a un beneficio:
Significa que cualquier librería / API con la que estés trabajando está perfectamente dispuesta a trabajar con objetos Java que no hayan sido manipulados o maltratados de ninguna manera, es decir, no tienes que hacer nada especial para que funcionen.
Por ejemplo, el procesador XStream XML (creo) felizmente serializará las clases de Java que no implementan la interfaz Serializable . ¡Eso es una ventaja! Muchos productos que funcionan con objetos de datos solían forzarlo a implementar SomeProprietaryDataObject o incluso ampliar una clase AbstractProprietaryDataObject . Muchas bibliotecas esperarán comportamiento del frijol, es decir, getters y setters.
Por lo general, lo que funcione con POJOs también funcionará con not-so-PO-JO. Por lo tanto, XStream también serializará las clases de Serializable.
Un Objeto Java Plain Old (POJO) que contiene toda la lógica de negocios para su extensión.
Exp. Pojo que contiene un solo método
public class Extension {
public static void logInfo(String message) {
System.out.println(message);
}
}
Según Martin Fowler , él y algunos otros lo propusieron como una forma de describir algo que era una clase estándar en comparación con un EJB, etc.
Objeto Java simple antiguo El nombre se utiliza para enfatizar que un objeto determinado es un objeto Java ordinario, no un objeto especial como los definidos por el marco EJB 2.
clase A {}
la clase B extiende / implementa C {}
Nota: B no es POJO cuando C es clase de clase de infraestructura distribuida o ifc. ej. javax.servlet.http.HttpServlet, javax.ejb.EntityBean o J2EE extn y no serializable / comparable. Dado que serializable / comparable son válidos para POJO.
Aquí A es un objeto simple que es independiente. B es un obj especial ya que B está extendiendo / implementando C. Por lo tanto, el objeto B obtiene un significado más de C y B es restrictivo para seguir las reglas de C. y B está estrechamente vinculado con el marco distribuido. Por lo tanto, el objeto B no es POJO desde su definición.
El código que utiliza la referencia de objeto de clase A no tiene que saber nada sobre el tipo de él, y se puede usar con muchos marcos.
Por lo tanto, un POJO no debería tener que 1) ampliar las clases preespecificadas y 2) Implementar las interfaces preespecificadas.
JavaBean es un ejemplo de POJO que es serializable, tiene un constructor sin argumentos, y permite el acceso a las propiedades usando los métodos getter y setter que siguen una convención de nomenclatura simple.
POJO se centra exclusivamente en la lógica empresarial y no tiene dependencias en los marcos (empresariales). Significa que tiene el código para la lógica de negocios, pero cómo se crea esta instancia, a qué servicio (EJB ..) pertenece este objeto y cuáles son sus características especiales (Stateful / Stateless) que tiene serán decididas por los marcos utilizando xml externo archivo.
Ejemplo 1: JAXB es el servicio para representar el objeto java como XML; Estos objetos java son simples y se presentan con getters y setters de constructor por defecto.
Ejemplo 2: Hibernate donde se usará la clase java simple para representar una tabla. las columnas serán sus instancias.
Ejemplo 3: servicios REST. En los servicios REST tendremos Service Layer y Dao Layer para realizar algunas operaciones sobre DB. Así que Dao tendrá consultas y operaciones específicas del proveedor. Service Layer será responsable de llamar a la capa DAO para realizar operaciones DB. Crear o actualizar la API (métodos) de DAO será tomar POJO como argumentos, actualizar esos POJO e insertar / actualizar en DB. Estos POJO (clase Java) solo tendrán estados (variables de instancia) de cada columna y sus getters y setters.
En la práctica, algunas personas consideran que las anotaciones son elegantes, mientras que consideran que XML es detallado, feo y difícil de mantener, mientras que otras encuentran que las anotaciones contaminan el modelo POJO. Por lo tanto, como alternativa al XML, muchos marcos (por ejemplo, Spring, EJB y JPA) permiten que las anotaciones se utilicen en su lugar o además de XML:
Ventajas:
Desacoplar el código de la aplicación de los marcos de infraestructura es uno de los muchos beneficios de usar POJO. El uso de POJOs a prueba la lógica de negocios de su aplicación desvinculando los marcos de infraestructura volátiles y en constante evolución. Actualizar a una nueva versión o cambiar a un marco diferente se vuelve más fácil y menos arriesgado. Los POJO también facilitan las pruebas, lo que simplifica y acelera el desarrollo. La lógica de su negocio será más clara y simple porque no se enredará con el código de infraestructura