La persistencia de objetos en Java es uno de esos conceptos que al principio suena más complicado de lo que realmente es. Cuando empezamos a programar, creamos objetos, les damos valores, llamamos a métodos y vemos que todo funciona mientras el programa está abierto. Pero aparece una pregunta importante: ¿qué pasa con esos objetos cuando cerramos la aplicación?
La respuesta corta es: si no los guardamos en algún sitio, desaparecen.
Y ahí entra la persistencia de objetos en Java. Persistir información significa almacenarla de manera que pueda recuperarse en una ejecución posterior del programa. Es decir, que los datos no dependan únicamente de la memoria RAM, sino que puedan conservarse en un fichero, una base de datos, un servidor o cualquier sistema de almacenamiento permanente.
En mi caso, viniendo del desarrollo software y de la docencia en FP Informática, me gusta explicar este tema desde una idea muy simple: un programa útil no solo debe crear objetos; debe ser capaz de conservarlos, recuperarlos y mantenerlos coherentes. Da igual que estemos hablando de productos, libros, usuarios, reservas o préstamos. Si la información se pierde cada vez que cerramos la aplicación, tenemos un problema.
Por eso, entender la persistencia de objetos en Java es clave para pasar de programas “de prueba” a aplicaciones que empiezan a comportarse como sistemas reales.
Qué significa persistir objetos en Java
Cuando hablamos de persistencia de objetos en Java, hablamos de guardar el estado de un objeto para poder recuperarlo más adelante. Un objeto tiene atributos, relaciones y comportamiento. Mientras el programa se está ejecutando, ese objeto vive en memoria. Pero la memoria RAM es temporal: al cerrar la aplicación, todo lo que no se haya guardado desaparece.
Imagina este ejemplo:
Producto p = new Producto("P001", "Teclado mecánico", 49.99);
System.out.println(p.getNombre());Ese objeto Producto existe mientras el programa está en marcha. Tiene un código, un nombre y un precio. Podemos mostrarlo por pantalla, modificarlo o pasarlo a otros métodos. Pero si el programa termina ahí y no hacemos nada más, el objeto se pierde.
La persistencia de objetos en Java busca justo lo contrario: que ese producto siga existiendo cuando abramos de nuevo la aplicación.
Objeto transitorio vs objeto persistente
Para entender bien la persistencia de objetos en Java, conviene diferenciar dos ideas:
Un objeto transitorio es aquel que solo existe durante la ejecución del programa. Lo creamos con new, lo usamos y, cuando el programa termina, desaparece.
Un objeto persistente es aquel cuyo estado se guarda en un soporte permanente. Puede estar almacenado en una base de datos, en un fichero o en otro sistema de almacenamiento. La clave es que puede recuperarse después.
Esta diferencia parece básica, pero en la práctica cambia por completo cómo diseñamos una aplicación. No es lo mismo crear una lista de productos en memoria para hacer una prueba rápida que diseñar una aplicación donde esos productos deben conservarse entre ejecuciones.
Cuando explico este tema en clase, suelo llevarlo a ejemplos cercanos: si una aplicación de biblioteca se cierra, ¿deben perderse los libros, los usuarios y los préstamos? Evidentemente no. Si una aplicación de tienda se reinicia, ¿debería perder todo el catálogo? Tampoco. Ahí es donde la persistencia deja de ser un concepto teórico y se convierte en una necesidad real.
El estado y la identidad del objeto
En persistencia de objetos en Java, no basta con guardar “datos sueltos”. Un objeto tiene un estado, que es el conjunto de valores de sus atributos en un momento determinado. Por ejemplo, un libro puede tener ISBN, título, año de publicación, autor y disponibilidad.
Pero también necesitamos identidad. La identidad permite reconocer un objeto concreto aunque cambien algunos de sus datos. Por ejemplo, un libro puede cambiar de título o de disponibilidad, pero su ISBN puede seguir identificándolo.
Esta idea es muy importante porque, si no definimos bien cómo reconocer cada objeto, aparecen problemas: duplicados, búsquedas incorrectas, actualizaciones sobre el objeto equivocado o relaciones rotas.
En desarrollo software, pensar con estructura es clave. Antes de guardar nada, hay que preguntarse: ¿qué objeto quiero conservar?, ¿qué atributos forman su estado?, ¿qué campo lo identifica?, ¿con qué otros objetos se relaciona?
Formas habituales de persistencia
La persistencia de objetos en Java puede resolverse de varias formas. No todas sirven para lo mismo, y no siempre la solución más potente es la mejor.
Ficheros de texto
Los ficheros de texto son una opción sencilla para guardar información pequeña o configuración básica. Son fáciles de revisar y no requieren un gestor de base de datos. Por ejemplo, podríamos guardar una configuración simple de una aplicación.
El problema es que tienen poca estructura. Buscar datos, mantener relaciones o evitar errores de formato se vuelve complicado cuando el sistema crece.
Para una práctica pequeña, un fichero puede estar bien. Para un sistema con objetos relacionados, se queda corto rápidamente.
Serialización de objetos
La serialización permite guardar objetos completos convirtiéndolos en datos almacenables. En Java, una clase puede implementar Serializable y después guardarse mediante flujos de objetos.
Un ejemplo sencillo sería:
import java.io.Serializable;
public class Producto implements Serializable {
private String codigo;
private String nombre;
private double precio;
public Producto(String codigo, String nombre, double precio) {
this.codigo = codigo;
this.nombre = nombre;
this.precio = precio;
}
public String getCodigo() {
return codigo;
}
public String getNombre() {
return nombre;
}
public double getPrecio() {
return precio;
}
}Después podríamos guardar una lista de productos en un fichero y recuperarla al volver a ejecutar el programa. Esta técnica ayuda mucho a entender la persistencia de objetos en Java, porque demuestra que un objeto puede sobrevivir al cierre de la aplicación.
Ahora bien, la serialización no sustituye a una base de datos orientada a objetos real. Es útil para aprender, para simular persistencia o para casos muy controlados, pero tiene limitaciones cuando necesitamos consultas complejas, cambios de versión, relaciones más elaboradas o gestión avanzada.
Bases de datos relacionales y ORM
Las bases de datos relacionales son muy habituales en aplicaciones empresariales. Trabajan con tablas, filas, claves primarias y claves ajenas. Son potentes para consultas, informes y transacciones.
El problema, desde el punto de vista de la programación orientada a objetos, es que los objetos deben transformarse en tablas. Un objeto Libro puede terminar dividido en filas, columnas y relaciones mediante claves. Esto funciona muy bien, pero exige un mapeo entre el mundo de los objetos y el mundo relacional.
Ahí aparecen los ORM, que permiten trabajar con objetos sobre una base de datos relacional. El ORM facilita esa conversión, aunque también añade configuración y puede ocultar consultas complejas.
Bases de datos orientadas a objetos
Una base de datos orientada a objetos almacena información de forma cercana al modelo del programa. En lugar de pensar principalmente en tablas y filas, trabaja con clases, objetos, atributos, métodos, referencias, colecciones, herencia e identidad.
Para la persistencia de objetos en Java, este enfoque resulta muy natural, porque el modelo de datos se parece más al modelo de clases de la aplicación.
No significa que una base de datos orientada a objetos sea siempre mejor que una relacional. Significa que es una alternativa distinta y que puede encajar muy bien cuando el programa trabaja con objetos complejos, relaciones profundas o estructuras muy conectadas.
Qué es una base de datos orientada a objetos
Una base de datos orientada a objetos, también conocida como OODB, permite almacenar objetos siguiendo conceptos propios de la programación orientada a objetos. Cuando hablamos del gestor, también puede aparecer el término ODBMS.
La idea principal es sencilla: si en Java trabajamos con clases y objetos, ¿por qué no guardar esos objetos de una forma más directa?
En una OODB, una clase define el tipo de objetos que pueden almacenarse. Un objeto es la unidad de información persistente. Los atributos representan los datos del objeto. Las referencias permiten relacionar unos objetos con otros. Las colecciones agrupan objetos o valores. Y la identidad permite distinguir un objeto concreto frente a otros.
Esto encaja muy bien con la persistencia de objetos en Java porque reduce la distancia entre el código y el almacenamiento.
Diferencias frente a una base de datos relacional
En una base de datos relacional, la unidad principal es la tabla y la fila. Las relaciones se modelan mediante claves primarias y claves ajenas. Las consultas suelen hacerse con SQL.
En una base de datos orientada a objetos, la unidad principal es la clase y el objeto. Las relaciones pueden representarse mediante referencias directas entre objetos. Las consultas pueden realizarse mediante un lenguaje de consulta de objetos o mediante la API del gestor.
La diferencia no es solo técnica; también es mental.
Cuando trabajamos con una base relacional, solemos pensar: “¿qué tablas necesito?”
Cuando trabajamos con persistencia de objetos en Java mediante una OODB, la pregunta suele ser: “¿qué objetos necesito conservar y cómo se relacionan?”
Desde mi experiencia en proyectos y formación, este cambio de enfoque ayuda mucho a estudiantes que ya están aprendiendo programación orientada a objetos. Si ya entienden clases, atributos, métodos y relaciones, la base de datos orientada a objetos puede ser una forma muy directa de conectar programación y persistencia.
Características principales de una OODB
Las bases de datos orientadas a objetos pueden almacenar objetos completos, conservar su estado entre ejecuciones y mantener relaciones mediante referencias. También pueden soportar tipos compuestos, colecciones, herencia, polimorfismo, consultas, actualizaciones y borrados.
Además, según el gestor utilizado, pueden incorporar transacciones, índices, bloqueo y control de concurrencia.
Para un proyecto educativo o una práctica de Java, esto permite trabajar la persistencia de objetos en Java sin abandonar el paradigma orientado a objetos. El alumno no tiene que traducir constantemente entre clases y tablas, sino que puede centrarse en diseñar bien sus objetos y operaciones.
Cuándo tiene sentido usar una OODB
Una OODB puede tener mucho sentido cuando la aplicación trabaja con estructuras de objetos complejas, relaciones profundas y un modelo de dominio ya definido en clases.
Por ejemplo, en un sistema de biblioteca podemos tener autores, libros, usuarios, préstamos y bibliotecas. Un libro tiene autor. Un préstamo relaciona usuario y libro. Una biblioteca puede contener una colección de libros. Todo eso forma un grafo de objetos.
La persistencia de objetos en Java encaja especialmente bien cuando lo importante no es solo guardar datos aislados, sino conservar relaciones entre objetos.
Casos donde puede encajar bien
Una OODB puede ser interesante en aplicaciones científicas o de ingeniería, donde se manejan objetos complejos con muchos atributos y relaciones.
También puede tener sentido en sistemas con grafos de objetos, donde las referencias directas resultan más naturales que múltiples uniones entre tablas.
En modelos con herencia, una base de datos orientada a objetos puede trasladar mejor la estructura de clases al almacenamiento.
En aplicaciones embebidas, de escritorio o prototipos educativos, una OODB o una simulación con serialización puede simplificar la persistencia local.
En consultoría aprendí algo que también aplico en docencia: antes de proponer una herramienta, hay que entender el problema. No se trata de decir “usa una OODB porque sí”, sino de analizar si el modelo de objetos pide ese tipo de solución.
Cuándo no es la mejor opción
Una base de datos orientada a objetos no siempre es la mejor respuesta. Si el sistema necesita integrarse con muchas herramientas que esperan SQL, una base relacional puede ser más práctica.
Si el equipo domina claramente bases de datos relacionales y no hay una ventaja real en cambiar, forzar una OODB puede complicar el proyecto.
Si se requieren informes tabulares complejos, consultas analíticas intensivas o mucha integración con herramientas externas, el modelo relacional suele ser más cómodo.
Y si el modelo de datos es muy simple, quizá no merece la pena introducir una solución más específica. La persistencia de objetos en Java debe elegirse con criterio, no por moda.
Cómo diseñar objetos persistentes
Antes de guardar objetos, hay que diseñarlos bien. Esta parte es fundamental. La persistencia no arregla un mal modelo; de hecho, puede hacerlo más evidente.
Para diseñar objetos persistentes, conviene hacerse varias preguntas:
| Elemento | Pregunta clave |
|---|---|
| Clase persistente | ¿Qué entidad necesito conservar entre ejecuciones? |
| Atributos | ¿Qué datos forman el estado del objeto? |
| Identificador | ¿Cómo reconoceré cada objeto? |
| Relaciones | ¿Qué otros objetos están asociados? |
| Colecciones | ¿El objeto contiene listas o conjuntos? |
| Reglas de integridad | ¿Qué valores no deberían permitirse? |
| Operaciones | ¿Qué métodos representan comportamiento real? |
Este análisis previo es parte esencial de la persistencia de objetos en Java.
Ejemplo de clase persistente
Una clase Libro puede tener ISBN, título, año de publicación y autor:
public class Libro {
private String isbn;
private String titulo;
private int anioPublicacion;
private Autor autor;
public Libro(String isbn, String titulo, int anioPublicacion, Autor autor) {
this.isbn = isbn;
this.titulo = titulo;
this.anioPublicacion = anioPublicacion;
this.autor = autor;
}
public String getIsbn() {
return isbn;
}
public String getTitulo() {
return titulo;
}
public Autor getAutor() {
return autor;
}
public void cambiarTitulo(String nuevoTitulo) {
this.titulo = nuevoTitulo;
}
}Aquí vemos datos simples, como isbn o titulo, y una relación con otro objeto: Autor.
public class Autor {
private String nombre;
private String nacionalidad;
public Autor(String nombre, String nacionalidad) {
this.nombre = nombre;
this.nacionalidad = nacionalidad;
}
public String getNombre() {
return nombre;
}
public String getNacionalidad() {
return nacionalidad;
}
}En una OODB, esa relación entre Libro y Autor puede almacenarse como una referencia directa entre objetos. Esto hace que la persistencia de objetos en Java sea más cercana al modo en el que ya pensamos el programa.
Tipos compuestos y colecciones
También podemos tener objetos que contienen colecciones:
import java.util.ArrayList;
import java.util.List;
public class Biblioteca {
private String nombre;
private List<Libro> libros;
public Biblioteca(String nombre) {
this.nombre = nombre;
this.libros = new ArrayList<>();
}
public void agregarLibro(Libro libro) {
libros.add(libro);
}
public List<Libro> getLibros() {
return libros;
}
}Aquí Biblioteca contiene una lista de Libro. Eso ya no es un dato simple, sino una estructura más rica. La persistencia debe conservar no solo la biblioteca, sino también su colección y las relaciones entre los objetos.
Esto es lo que en programación orientada a objetos llamamos un modelo más conectado. Y justo en ese tipo de modelos es donde la persistencia de objetos en Java empieza a cobrar más sentido.
Identidad de objeto
La identidad de objeto permite distinguir un objeto concreto de otros. Dos objetos pueden tener los mismos valores y, aun así, ser objetos diferentes. En persistencia, esto es especialmente importante.
Podemos hablar de varios tipos de identidad:
| Tipo de identidad | Explicación | Ejemplo |
|---|---|---|
| Identidad por referencia | Depende de la instancia en memoria | Dos variables apuntan a objetos distintos |
| Identidad lógica | Usa un atributo único del dominio | ISBN de un libro, código de producto, email |
| Identidad interna del gestor | La base de datos asigna un identificador | OID interno |
En aplicaciones educativas, suele ser muy útil usar un identificador lógico claro. Por ejemplo, el ISBN en un libro, el código en un producto o el email en un usuario.
Cuando trabajo con alumnado, insisto mucho en esto: si no sabes identificar un objeto, luego no podrás buscarlo, actualizarlo ni borrarlo con seguridad.
Equals y hashCode
En Java, cuando trabajamos con colecciones y objetos persistentes, puede ser importante definir cuándo dos objetos se consideran iguales. Esto se hace sobrescribiendo equals y hashCode.
Por ejemplo, en una clase Libro, podríamos decir que dos libros son iguales si tienen el mismo ISBN:
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (!(obj instanceof Libro)) return false;
Libro otro = (Libro) obj;
return isbn.equals(otro.isbn);
}
@Override
public int hashCode() {
return isbn.hashCode();
}Eso sí: si un atributo se usa como identidad lógica, no debería cambiarse alegremente. Modificar un identificador puede provocar duplicados, referencias rotas o comportamientos inesperados.
La persistencia de objetos en Java necesita estabilidad. No basta con guardar objetos; hay que guardarlos de forma coherente.
Operaciones CRUD sobre objetos persistentes
CRUD resume las cuatro operaciones básicas de casi cualquier sistema persistente:
| Operación | Significado | Ejemplo |
|---|---|---|
| Create | Crear o almacenar | Guardar un nuevo libro |
| Read | Leer o recuperar | Buscar libros de un autor |
| Update | Actualizar | Cambiar el título o el año |
| Delete | Eliminar | Borrar un libro descatalogado |
La persistencia de objetos en Java debe permitir estas operaciones de forma clara. Da igual si usamos una OODB, serialización o una capa intermedia: tarde o temprano necesitaremos crear, leer, actualizar y eliminar objetos.
Flujo general de trabajo
Un flujo habitual en persistencia sería:
- Abrir conexión o base de datos.
- Iniciar transacción si el gestor lo requiere.
- Crear, consultar, modificar o eliminar objetos.
- Confirmar cambios con
commit. - Deshacer cambios con
rollbacksi hay error. - Cerrar correctamente la base de datos.
Este flujo es importante porque evita pérdidas de datos y estados inconsistentes. En programación, muchas veces el problema no está en guardar algo, sino en guardar solo una parte de lo que debería haberse guardado.
Crear y guardar objetos
Un ejemplo conceptual de almacenamiento podría ser:
Autor autor = new Autor("Mary Shelley", "Reino Unido");
Libro libro = new Libro("978-0000000001", "Frankenstein", 1818, autor);
baseDatos.guardar(autor);
baseDatos.guardar(libro);
baseDatos.confirmar();La sintaxis exacta dependerá del gestor, pero la idea es siempre parecida: creamos objetos, los enviamos al sistema de persistencia y confirmamos la operación.
Buscar y recuperar objetos
Para recuperar objetos, podemos consultar por tipo, atributo, relación o colección. Por ejemplo:
List<Libro> libros = baseDatos.buscar(
Libro.class,
libro -> libro.getAutor().getNombre().equals("Mary Shelley")
);
for (Libro l : libros) {
System.out.println(l.getTitulo());
}En este caso buscamos libros cuyo autor se llame “Mary Shelley”. Este tipo de consulta muestra una de las ideas potentes de la persistencia de objetos en Java: podemos pensar en objetos y relaciones, no solo en columnas.
Actualizar objetos
Actualizar un objeto implica modificar su estado y persistir el cambio. Por ejemplo, cambiar el título de un libro:
libro.cambiarTitulo("Nuevo título");
baseDatos.actualizar(libro);
baseDatos.confirmar();Lo importante es entender que el cambio debe quedar guardado. Si modificamos el objeto en memoria pero no confirmamos la operación, al volver a abrir la aplicación podríamos encontrar el valor antiguo.
Eliminar objetos
Eliminar objetos requiere especial cuidado. No es lo mismo borrar un producto aislado que borrar un libro que está relacionado con préstamos.
Antes de eliminar, hay que revisar dependencias. Si un préstamo apunta a un libro eliminado, podemos crear una referencia rota. Por eso, en persistencia de objetos en Java, el borrado debe diseñarse con reglas claras.
Consultas sobre objetos
Los gestores orientados a objetos pueden ofrecer varios mecanismos de consulta. Algunos usan lenguajes similares a SQL, otros ofrecen APIs propias y otros permiten filtros o expresiones del lenguaje de programación.
Las consultas pueden ser:
| Tipo de consulta | Ejemplo |
|---|---|
| Consulta por tipo | Todos los objetos Libro |
| Consulta por atributo | Libros con año mayor que 2000 |
| Consulta por relación | Libros cuyo autor tenga nacionalidad española |
| Consulta por colección | Bibliotecas con más de 100 libros |
| Consulta con operadores | Precio menor que 20 y stock mayor que 0 |
Esta parte es clave en la persistencia de objetos en Java porque guardar objetos no sirve de mucho si luego no podemos encontrarlos bien.
Cuidado con las consultas
Una mala consulta puede hacer que una aplicación sea lenta, confusa o difícil de mantener.
Algunas recomendaciones prácticas:
- No consultes todos los objetos si solo necesitas unos pocos.
- Usa identificadores cuando tenga sentido.
- Comprueba qué ocurre si no hay resultados.
- Evita modificar colecciones mientras las recorres si no sabes qué efecto tendrá.
- Documenta las consultas importantes.
En proyectos reales, he visto muchas veces que el problema no está en “no saber programar”, sino en mezclar demasiadas responsabilidades. Una consulta mal planteada, un borrado sin revisar o una actualización sin confirmar pueden generar errores difíciles de seguir.
Por eso, la persistencia de objetos en Java debe ir acompañada de orden.
Transacciones, integridad y consistencia
Persistir objetos no consiste solo en guardarlos. También hay que mantener la información correcta, coherente y recuperable.
La integridad evita datos imposibles o relaciones rotas. La consistencia evita que la base de datos quede a medias después de una operación.
Algunos riesgos frecuentes son:
| Riesgo | Ejemplo | Prevención |
|---|---|---|
| Objeto duplicado | Dos libros con el mismo ISBN | Validar identificadores únicos |
| Referencia rota | Un préstamo apunta a un libro eliminado | Controlar borrados y relaciones |
| Dato inválido | Año de publicación negativo | Validar antes de guardar |
| Operación incompleta | Se guarda el préstamo, pero no cambia la disponibilidad | Usar transacciones |
| Pérdida de cambios | No se confirma una actualización | Cerrar y confirmar correctamente |
Qué son commit y rollback
Una transacción agrupa varias operaciones que deben completarse juntas. Si todo va bien, se confirma con commit. Si ocurre un error, se deshace con rollback.
Por ejemplo:
try {
baseDatos.begin();
baseDatos.guardar(prestamo);
libro.marcarComoNoDisponible();
baseDatos.actualizar(libro);
baseDatos.commit();
} catch (Exception e) {
baseDatos.rollback();
System.out.println("No se pudo completar el préstamo");
}El ejemplo es muy claro: prestar un libro implica crear el préstamo y cambiar la disponibilidad del libro. No tendría sentido hacer solo una de las dos cosas.
Esta es una de las lecciones más importantes de la persistencia de objetos en Java: muchas operaciones reales no son pasos aislados, sino conjuntos de acciones que deben completarse juntas.
Cuando explico esto en clase, suelo decirlo de forma sencilla: o se hace todo bien, o no se hace nada. Eso es mucho más seguro que dejar el sistema en un estado raro.
Patrón repositorio en persistencia de objetos
El patrón repositorio ayuda a no mezclar el código de la aplicación con los detalles de almacenamiento.
En lugar de guardar, buscar o eliminar objetos directamente desde el menú o desde la clase principal, creamos una clase repositorio que concentra esas operaciones.
Por ejemplo:
import java.util.ArrayList;
import java.util.List;
public class ProductoRepository {
private List<Producto> productos = new ArrayList<>();
public void guardar(Producto producto) {
productos.add(producto);
}
public Producto buscarPorCodigo(String codigo) {
for (Producto p : productos) {
if (p.getCodigo().equals(codigo)) {
return p;
}
}
return null;
}
public boolean eliminar(String codigo) {
Producto p = buscarPorCodigo(codigo);
if (p != null) {
productos.remove(p);
return true;
}
return false;
}
}En una versión real, el repositorio llamaría al gestor OODB, a una capa de serialización o a cualquier sistema de almacenamiento. La aplicación no debería depender directamente de los detalles internos del gestor.
Separar modelo, repositorio y aplicación
Una estructura sencilla de proyecto podría ser:
Proyecto Java
├── src/
│ ├── modelo/
│ │ ├── Libro.java
│ │ ├── Autor.java
│ │ └── Prestamo.java
│ ├── repositorio/
│ │ └── LibroRepository.java
│ └── app/
│ └── Main.java
└── datos/
└── biblioteca.odbEl modelo define los objetos.
El repositorio concentra las operaciones de persistencia.
La aplicación coordina los casos de uso.
Esta separación mejora la claridad del código. Y aquí conecto mucho con mi forma de trabajar: tanto en desarrollo como en docencia, prefiero estructuras que se entiendan. Un programa puede funcionar hoy, pero si está todo mezclado, mañana será difícil de mantener.
La persistencia de objetos en Java se aprende mejor cuando el proyecto está ordenado.
Ejemplo práctico: biblioteca orientada a objetos
Un buen ejemplo para practicar persistencia de objetos en Java es una aplicación de biblioteca.
Podemos tener estas clases:
| Clase | Atributos principales | Relaciones |
|---|---|---|
| Autor | nombre, nacionalidad | Puede estar asociado a varios libros |
| Libro | isbn, título, año, disponible | Tiene un autor |
| Usuario | id, nombre, correo | Puede tener préstamos |
| Prestamo | fechaInicio, fechaFin, devuelto | Relaciona usuario y libro |
| Biblioteca | nombre, libros | Contiene una colección de libros |
Este caso es muy útil porque combina objetos, relaciones, reglas de negocio, CRUD y transacciones.
Reglas básicas del sistema
Algunas reglas podrían ser:
- No puede haber dos libros con el mismo ISBN.
- No se puede prestar un libro que no esté disponible.
- Al crear un préstamo, el libro pasa a no disponible.
- Al devolver un préstamo, el libro vuelve a estar disponible.
- No deben guardarse usuarios sin nombre o sin correo.
- Las operaciones importantes deben documentarse y probarse.
Estas reglas muestran que persistir no es solo guardar. También hay que validar.
Clase Libro
public class Libro {
private String isbn;
private String titulo;
private int anio;
private boolean disponible;
private Autor autor;
public Libro(String isbn, String titulo, int anio, Autor autor) {
this.isbn = isbn;
this.titulo = titulo;
this.anio = anio;
this.autor = autor;
this.disponible = true;
}
public String getIsbn() {
return isbn;
}
public String getTitulo() {
return titulo;
}
public boolean isDisponible() {
return disponible;
}
public void prestar() {
disponible = false;
}
public void devolver() {
disponible = true;
}
}Clase Prestamo
import java.time.LocalDate;
public class Prestamo {
private Usuario usuario;
private Libro libro;
private LocalDate fechaInicio;
private LocalDate fechaFin;
private boolean devuelto;
public Prestamo(Usuario usuario, Libro libro) {
if (!libro.isDisponible()) {
throw new IllegalStateException("El libro no está disponible");
}
this.usuario = usuario;
this.libro = libro;
this.fechaInicio = LocalDate.now();
this.devuelto = false;
libro.prestar();
}
public void devolver() {
devuelto = true;
fechaFin = LocalDate.now();
libro.devolver();
}
}Este ejemplo resume muy bien la persistencia de objetos en Java: Prestamo relaciona Usuario y Libro, y además modifica el estado del libro. Por eso, en una base de datos real, esta operación debería realizarse dentro de una transacción.
Grafo de objetos
Cuando varios objetos se relacionan entre sí, forman un grafo de objetos. La persistencia debe conservar no solo cada objeto por separado, sino también sus relaciones.
Por ejemplo:
Usuario usuario = new Usuario("U001", "Ana", "[email protected]");
Autor autor = new Autor("Miguel de Cervantes", "España");
Libro libro = new Libro("978-0000000002", "Don Quijote", 1605, autor);
Prestamo prestamo = new Prestamo(usuario, libro);Aquí Prestamo conecta Usuario y Libro. A su vez, Libro conecta con Autor. Si guardamos mal estos objetos, podemos recuperar datos incompletos o incoherentes.
Por eso, en persistencia de objetos en Java, las relaciones importan tanto como los propios objetos.
Errores frecuentes al trabajar con objetos persistentes
La persistencia de objetos en Java suele fallar menos por la teoría y más por pequeños descuidos de diseño.
No definir identificadores claros
Si guardamos objetos sin un identificador claro, luego será difícil buscarlos, actualizarlos o eliminarlos.
Un producto debería tener código.
Un libro debería tener ISBN.
Un usuario debería tener id o correo.
Sin identidad, el sistema se vuelve ambiguo.
Duplicar objetos relacionados
Otro error frecuente es crear objetos relacionados sin comprobar si ya existen. Por ejemplo, guardar varias veces el mismo autor porque cada libro lo crea de nuevo.
La solución es buscar antes de crear y controlar la unicidad.
No cerrar la base de datos
No cerrar correctamente el sistema de persistencia puede provocar pérdidas de datos o bloqueos. Siempre conviene usar cierres controlados y estructuras seguras.
No confirmar transacciones
Si hacemos cambios pero no ejecutamos commit, esos cambios pueden no quedar persistidos. Este error es muy típico cuando se empieza con persistencia de objetos en Java.
Borrar sin revisar relaciones
Eliminar objetos relacionados sin analizar el impacto puede dejar referencias rotas. Si un préstamo activo apunta a un libro, no deberíamos borrar ese libro sin control.
Mezclar menú, lógica y persistencia
Cuando todo está en la misma clase, el código se vuelve difícil de mantener. Lo ideal es separar modelo, repositorio y aplicación.
Este punto lo considero fundamental. En mi forma de enseñar, intento que el alumnado no solo consiga que “funcione”, sino que entienda por qué una estructura clara le ahorrará problemas más adelante.
No probar la segunda ejecución
Una prueba de persistencia no está completa hasta que cerramos la aplicación, la abrimos de nuevo y comprobamos que los datos siguen ahí.
Esta es una frase que repetiría sin cansarme: si no pruebas la segunda ejecución, no has comprobado la persistencia.
Buenas prácticas para persistencia de objetos en Java
Para trabajar bien la persistencia de objetos en Java, conviene seguir algunas buenas prácticas:
- Diseñar primero las clases del dominio antes de pensar en la base de datos.
- Usar nombres claros para clases, atributos y métodos.
- Definir identificadores lógicos cuando tenga sentido.
- Validar los datos antes de guardarlos.
- Separar el código de persistencia del código de interfaz o menú.
- Documentar cómo se instala y configura el gestor usado.
- Probar crear, leer, actualizar y eliminar.
- Comprobar que los datos siguen existiendo tras cerrar y abrir la aplicación.
- Gestionar errores con mensajes comprensibles.
- No borrar objetos relacionados sin analizar el impacto.
Estas prácticas convierten la persistencia de objetos en Java en algo más sólido. No se trata solo de guardar objetos “como sea”, sino de construir una base de trabajo mantenible.
En desarrollo, en consultoría y en docencia he aprendido que la tecnología funciona mejor cuando se explica y se estructura bien. La persistencia es un ejemplo perfecto: si entiendes el ciclo crear, guardar, consultar, modificar, eliminar y validar, tienes mucho ganado.
Mini práctica recomendada
Una práctica muy útil para aprender persistencia de objetos en Java es crear una aplicación de consola para gestionar productos persistentes.
La práctica podría tener estos requisitos:
| Requisito | Descripción |
|---|---|
| Clase Producto | código, nombre, precio y stock |
| Identidad | el código del producto debe ser único |
| Repositorio | métodos guardar, buscar, listar, actualizar y eliminar |
| Persistencia | los productos deben recuperarse tras cerrar y abrir |
| Validación | no permitir precio negativo ni stock negativo |
| CRUD | menú con alta, consulta, modificación, borrado y listado |
| Pruebas | comprobar operaciones normales, errores y segunda ejecución |
| Documentación | explicar estructura y funcionamiento |
Este ejercicio es muy completo porque obliga a aplicar lo esencial: clase persistente, identidad, repositorio, CRUD, validaciones y prueba real de persistencia.
Además, permite empezar con una simulación con serialización y después avanzar hacia una OODB o hacia el gestor que se indique en clase.
Resumen final
La persistencia de objetos en Java consiste en conservar objetos más allá de la ejecución del programa. Un objeto creado con new vive en memoria, pero si no se guarda, desaparece al cerrar la aplicación.
Para resolverlo, podemos usar ficheros, serialización, bases de datos relacionales, ORM o bases de datos orientadas a objetos. Cada opción tiene ventajas y limitaciones.
Las bases de datos orientadas a objetos encajan especialmente bien cuando trabajamos con modelos ricos en clases, objetos, relaciones, colecciones, herencia e identidad. No son siempre mejores que las relacionales, pero pueden ser muy naturales cuando el programa ya está diseñado desde la programación orientada a objetos.
La persistencia de objetos en Java también exige entender CRUD, consultas, identidad, transacciones, integridad, consistencia y patrón repositorio. Guardar datos no es suficiente: hay que poder recuperarlos, modificarlos, eliminarlos y mantenerlos coherentes.
Al final, un programa orientado a objetos cobra mucho más valor cuando sus objetos no solo existen en memoria, sino que pueden conservarse, recuperarse y evolucionar de forma segura.
Preguntas frecuentes sobre persistencia de objetos en Java
¿Qué es la persistencia de objetos en Java?
La persistencia de objetos en Java es la capacidad de guardar el estado de un objeto para recuperarlo en una ejecución posterior del programa. Permite que la información no dependa solo de la memoria RAM.
¿Qué diferencia hay entre un objeto transitorio y un objeto persistente?
Un objeto transitorio existe solo mientras el programa está en ejecución. Un objeto persistente se guarda en un soporte permanente, como una base de datos o un fichero, y puede recuperarse después.
¿Por qué un objeto creado con new desaparece al cerrar el programa?
Porque al crearlo con new, el objeto vive en memoria. Si no lo guardamos en un sistema persistente, se pierde cuando finaliza la ejecución.
¿Qué es una base de datos orientada a objetos?
Una base de datos orientada a objetos almacena información siguiendo conceptos de programación orientada a objetos, como clases, objetos, atributos, referencias, colecciones, herencia e identidad.
¿Qué diferencia hay entre una OODB y una base de datos relacional?
Una base relacional trabaja con tablas y filas. Una OODB trabaja con clases y objetos. En una relacional las relaciones se modelan con claves; en una orientada a objetos pueden conservarse mediante referencias entre objetos.
¿Cuándo conviene usar una base de datos orientada a objetos?
Puede convenir cuando el modelo tiene objetos complejos, muchas relaciones, herencia, colecciones o grafos de objetos. También puede ser útil en prototipos educativos y aplicaciones donde se quiera mantener el paradigma orientado a objetos.
¿Qué significa CRUD?
CRUD significa crear, leer, actualizar y eliminar. Son las operaciones básicas que debe permitir casi cualquier sistema persistente.
¿Por qué es importante el patrón repositorio?
Porque separa la lógica de persistencia del resto de la aplicación. Así el código queda más ordenado, mantenible y fácil de modificar.
¿Qué es una transacción?
Una transacción agrupa varias operaciones que deben completarse juntas. Si todo va bien, se confirma con commit. Si hay un error, se deshace con rollback.
¿Cómo puedo comprobar que la persistencia funciona?
La prueba clave es cerrar la aplicación, volver a abrirla y comprobar que los objetos siguen existiendo. Si los datos no se recuperan en una segunda ejecución, la persistencia no está bien comprobada.
