metodos y clases transient

Hola a todos, mi duda es acerca de las clases, variables y métodos definidos como transient, como se utilizan y para en un programa, tengo entendido que esu tilizado para indicar que los atributos de un objeto no son parte persistente del objeto o que estos no deben guardarse y restaurarse utilizando el mecanismo de serialización estándar, pero no entiendo muy bien.

Muchas gracias

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Si tienes una clase

Si tienes una clase así:

 

Al serializarla y des-serializarla ( al re constituirla ) el atributo:   será nulo.

 

:)

Dime si esto te sirve. Saludos.

Imagen de ezamudio

qué no entiendes?

Ya describiste el uso de los campos  , qué es lo que no entendiste?

¿Métodos y clases transient?

Hasta donde yo se ni los métodos, ni las clases pueden ser calificadas como transient, sólo los atributos (o variables como tu la llamas ) de una clase.

Cuando tienes un objeto (es decir, una instancia de una clase con sus atributos inicializados con datos) y quieres hacerlo persistente (guardarlo físicamente) normalmente lo haces persistente en un archivo en el file system, esto lo haces marcando tu clase con la interfaz de marcado llamada Serializable, Oscar ya te escribió la sintaxis.

Para serializar, puedes escribir un método que lo haga:
 

Con esto la información de tu objeto "objEjemplo" queda guardada en un archivo llamado test.ser, pero la información de los atributos marcados como transient NO se guarda, por ejemplo el que Oscar llamó "esteNoVa".

Cuando hagas el proceso de deserializar, es decir, recuperar la información de tu objeto guardada en tu archivo:
 

e imprimir a consola la información de tu objeto

objEjemplo.esteNoVa

te imprimirá null

No así con la información de tu atributo esteSiVa.

Saludos.

Post Data:

Ahora que lo pienso... una clase si puede ser calificada como transient, pero sólo en el caso de que se trate de agregación, es decir, cuando la clase esté jugando el papel de atributo de otra clase, de la siguiente forma:
 

Post Data 2:

Disculpas a Oscar si le molesta que haya usado su código.

@JuanR. Para nada, solo me

@JuanR.

Para nada, solo me causó un poco de ruido que pongas la llave que abre en una linea nueva :P

 

Jo jo jo </troleo>

Imagen de ezamudio

nop

esa clase no está jugando el papel de atributo. Simplemente tienes un atributo de tipo OtraClase y está inicializado a una instancia de OtraClase. Es exactamente lo mismo que el atributo "esteNoVa" de tipo String inicializado a una cadena.

ja ja ja

para Oscar:

ja ja ja... Si a esas vamos, creo que tendríamos muchas diferencias en el estilo de programación, en la indentación y además yo por ejemplo siento que me sirve mucho la notación Húngara (aunque allí no la haya usado), cosa que pienso que ya casi nadie usa, pero con un vistazo al código sabes de que tipo son los atributos.

Una vez alguien me dijo que no la usara, pero no me explicó ¿Porqué no?, el decía que para saber de que tipo era un atributo el sólo pasaba el mouse por encima estando dentro de un IDE y ya sabía de que tipo era, osea que aparte de la vista usaba la mano sobre el mouse para acceder a la ayuda que te proporciona un IDE.

¡En fin ! cuestión de enfoques y opiniones. Para eso se tendría que generar un nuevo tema para exponer ventajas y desventajas, o a lo mejor ya lo discutieron en este sitio, la verdad no me he fijado. Pero si existen más argumentos a favor de NO usar la notación o si es parte del estándar de java yo me ajustaría, si el cambio es para mejorar, ¡adelante!.

para ezamudio:

Creo que tienes todos los dedos llenos de razón, técnica y estrictamente hablando es como lo escribiste.

Je je si, es otra discusión y

Je je si, es otra discusión y la razón que te dió es malísima.

Si el paradigma es OO no tiene caso poner prefijos para denotar el tipo de dato pues el contexto lo da.

Ejemplo lo siguiente no tiene mucho caso:

 

Si se puede escribir directamente:

 

Ni siquiera cuando se están usando sin ver la definición:

 

Lo de las llaves, si, efectivamente es convención de Java, y cada lenguaje tiene las suyas. Cuando se escribe fuera de esas convenciones no pasa nada, simplemente se ve raro. Yo por ejemplo actualmente estoy escribiendo en C# y ni por un momento se me ocurre escribir con estilo Java. Lo anterior sería escrito:

 

Hacerlo de otra forma ( como en Java ) se vería mal.

Buena la observación de que   solo aplica a atributos, no a clases ni métodos.

Saludos.

¡Vale!

¡Vale!

Tus argumentos me parecen más convincentes. Aunque te diré que lo de las llaves el libro de

Java como programar
séptima edición
de Deitel

lo maneja como supuestamente no debe ser

 

Pero con el link que escribiste de convenciones de java ya no hay pierde.

Yo agarré esa costumbre de la notación porque en 2 consultorías que trabajé lo primero que me dieron los jefes fueron unos documentos de convenciones de como programar y aparte convenciones para crear tablas y objetos de base de datos, allí si hay que ajustarse a lo que te dicen, amenos que debatas con ellos y los hagas cambiar de parecer.

Salu2.

Imagen de ezamudio

C#?

En C#? las llaves deben ir en su propia línea? Ups creo que dejé unos miles de líneas de código con estilo incorrecto en Nasoft entonces...