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
- Inicie sesión o regístrese para enviar comentarios
Si tienes una clase
Si tienes una clase así:
public transient String esteNoVa = "Aunque tenga datos";
public String esteSiva = "Chanchan";
}
Al serializarla y des-serializarla ( al re constituirla ) el atributo:
esteNoVaserá nulo.Ejemplo e = reconstituir( serializado ); //
assert e.esteNoVa == null; // sería verdad
:)
Dime si esto te sirve. Saludos.
qué no entiendes?
Ya describiste el uso de los campos
transient, 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:
{
File f = new File("test.ser");
ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(f));
stream.writeObject(objEjemplo);
stream.flush();
stream.close();
}
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:
{
File f = new File("test.ser");
ObjectInputStream stream = new ObjectInputStream(new FileInputStream(f));
return (Ejemplo)stream.readObject();
}
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:
{
public transient String esteNoVa = "Aunque tenga datos";
public String esteSiva = "Chanchan";
transient OtraClase objOtraClase = new OtraClase();//Clase jugando el papel de atributo en la clase Ejemplo, calificado como transitorio
}
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
}
...
class AsiNo
{
}
Jo jo jo </troleo>
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:
int iEdad;
String sName;
}
Si se puede escribir directamente:
int edad;
String name;
}
Ni siquiera cuando se están usando sin ver la definición:
persona = getPersona( id ); // no importa mucho is id es int, long, biginteger, string o lo que sea... es el id para obtener a un persona
if ( persona.edad() > 18 ) { // puede comprar... es lo que nos importa.. no tiene caso: objPersona.intEdad() > 18
guardaNombre( persona.name() ); // igual, para que querríamos persona.sName();
}
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:
{
int Edad;
string Name;
}
...
persona = GetPersona( id );
if ( persona.Edad > 18 )
{
GuardaNombre( persona.Name );
}
Hacerlo de otra forma ( como en Java ) se vería mal.
Buena la observación de que
transientsolo 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.
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...