Diferencias

Muestra las diferencias entre dos versiones de la página.

--- bloque3:serializable [01/04/2019 18:13] – [Lectura de objetos en fichero] Fernando Valdeón
+++ bloque3:serializable [16/09/2024 20:53] (actual) – editor externo 127.0.0.1
@@ Línea 5: / Línea 5: @@
 ===== Interface Serializable =====
-Para que un programa en java pueda convertir un objeto en un montón de bytes y pueda luego recuperarlo, el objeto necesita ser Serializable. Al poder convertir el objeto a bytes, ese objeto se puede enviar a través de red, guardarlo en un fichero, y después reconstruirlo al otro lado de la red, leerlo del fichero, etc.
+Java ofrece un mecanismo llamado serialización de objetos, mediante el cual un objeto puede ser representado por una secuencia de //bytes// que incluye tanto los datos del objeto, como el tipo del objeto y los tipos de los datos que contiene ese objeto.
-Para que un objeto sea serializable debe implementar la interface Serializable. La interface Serializable es algo peculiar ya que no tiene métodos. Basta con implementarla y ya podremos serializar nuestros objetos.
+Gracias a esto podemos guardar el estado de un objeto en fichero o enviarlo por la red, y permite posteriormente leer esos bytes para reconstruir el objeto y su estado en la memoria de nuevo. Además puede ser serializado en una máquina y deserializado en otra máquina distinta.
+Para que un objeto sea serializable debe implementar la interface //Serializable//. Esta interface es algo peculiar ya que no tiene métodos; simplemente sirve para "marcar" las clases que permiten ser serializadas. Basta con implementarla y ya podremos serializar sus objetos.
 Hay que tener en cuenta que, para poder traducir un objeto a bytes de forma correcta, __todos los objetos que lo componen deben ser serializables__.
+**Los miembros estáticos de una clase, no son parte del estado de un objeto (sino de la clase) y no permiten ser serializados.**
 La mayoría de las clases de la [[https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html|API]] de Java implementan esta interface, pero nuestros objetos deben implementarla también si queremos serializarlos.
@@ Línea 27: / Línea 31: @@
 ==== Serial Version UID ====
-Cuando pasamos objetos Serializable de un lado a otro tenemos un pequeño problema. Si la clase que queremos pasar es Coche, lo normal es que en ambos lados (el que envía y el que recibe la clase), tengan su propia copia del fichero Coche.class.
+Cuando //serializamos// objetos para deserializarlos posteriormente debemos tener en cuenta un aspecto. Si la clase que queremos pasar es Coche, lo normal es que en ambos programas (el que serializa y el que deserializa), tengan su propia copia del fichero Coche.class.
-Pero también es posible que en distintas versiones de nuestro programa la clase Coche cambie, de forma que es posible que un lado tenga una versión más antigua que en el otro lado. Si sucede esto, la reconstrucción de la clase en el lado que recibe sera imposible.
+Pero también es posible que en distintas versiones de nuestro programa la clase Coche no sea igual, de forma que es posible que un lado tenga una versión más antigua que en el otro lado. Si sucede esto, la reconstrucción de la clase en el lado que recibe sera imposible.
 Para evitar este problema, se aconseja que la clase Coche tenga un atributo privado de esta forma:
@@ Línea 58: / Línea 62: @@
 File fichero = new File("fichero.bin");
 FileOutputStream flujoFichero = new FileOutputStream(fichero);
-ObjectOutputStream flujoObjetos = new ObjectOutputStream(flujoFichero);
+ObjectOutputStream serializador = new ObjectOutputStream(flujoFichero);
 </code>
@@ Línea 68: / Línea 72: @@
 // Escribir objetos en el fichero
-flujoObjetos.writeObject("Guardo 2 objetos Coche"); 	//Puedo almacenar objetos String
+serializador.writeObject("Guardo 2 objetos Coche"); 	// Puedo almacenar objetos String
-flujoObjetos.writeObject(miCoche1); 		   	// u objetos tipo Coche
+serializador.writeObject(miCoche1); 		   	// u objetos tipo Coche
-flujoObjetos.writeObject(miCoche2);
+serializador.writeObject(miCoche2);
 . . .
-flujoObjetos.close(); // Finalmente se cierran los flujos de salida, cerrando el más externo.
+serializador.close(); // Finalmente se cierran los flujos de salida, cerrando el más externo.
 </code>
@@ Línea 85: / Línea 89: @@
 <code java>
 File fichero = new File("fichero.bin");
-FileInputStream flujoFichero= new FileInputStream(fichero);
+FileInputStream flujoFichero = new FileInputStream(fichero);
-ObjectInputStream flujoObjetos = new ObjectInputStream(flujoFichero);
+ObjectInputStream deserializador = new ObjectInputStream(flujoFichero);
 // Leer el objeto del fichero (en el mismo orden !!)
-String cadena = (String) flujoObjetos.readObject(); 		//Leo el objeto tipo String
+String cadena = (String) flujoObjetos.readObject(); 	//Leo el objeto tipo String
-Coche cocheLeido1 = (Coche) flujoObjetos.readObject(); 	//Leo los objetos tipo Coche
+Coche cocheLeido1 = (Coche) deserializador.readObject(); 	//Leo los objetos tipo Coche
-Coche cocheLeido2 = (Coche) flujoObjetos.readObject();
+Coche cocheLeido2 = (Coche) deserializador.readObject();
-flujoObjetos.close();	//Finalmente se cierran los flujos de entrada
+deserializador.close();	//Finalmente se cierran los flujos de entrada
 </code>
@@ Línea 102: / Línea 106: @@
 En el caso de lectura de listas de objetos, nuestro programa no puede asegurar de ninguna forma que los bytes que lee del fichero son los tipos de datos que nosotros le indicamos:
 <code java>
-ArrayList<Coche> lista = (ArrayList<Coche>) entrada.readObject();
+ArrayList<Coche> lista = (ArrayList<Coche>) deserializador.readObject();
 </code>
 Aunque nosotros sepamos que se lee lo correcto no hay forma de que Java "lo sepa". Podríamos cambiar el fichero, y no leer el objeto que esperamos leer.