Serialização

[skcratch]

Viva!

Será que alguém me poderia explicar porque motivo quando quero persistir um determinado objecto no disco, a sua classe tem que implementar a interface Serializable?

Grato desde já pela ajuda!

Cumps!

😄

[magician]

Esse interface é que permite ao stream de leitura e escrita saber como escrever e ler os dados, embora a maioria das vezes esse interface apenas seja implementado e usado de forma genérica podes implementar os métodos do interface e dizer como queres que os dados sejam escritos e lidos.

[falk0n]

pq ao implementares essa interaface ficas com duas funcoes read e write (acho eu que sao estas funcoes) e sao essas duas funcoes que gravam e leem do disco 😄

bem entao como querias guardar os dados em disco ?

boas programacoes

[skcratch]

Viva!

Eu estou a desenvolver uma aplicação, para a qual defini as classes que pretendo persistir, recorrendo a EJB. Essas mesmas classes implementam a interface Serializable, porque caso contrário, não poderia haver persistência dos objectos, segundo aquilo que percebi.

Por outro lado, utilizo o Netbeans como IDE, o qual permite a criação de bases de dados, como todos devem saber. A minha dúvida está no seguinte aspecto: como defino uma persistence unit que me permite declarar a base de dados na qual irei armazenar as minhas classes, não percebo, à primeira vista, porque motivo as classes têm que implementar a interface Serializable, já que, do meu ponto de vista, isso deveria ser transparente ao utilizador e implementado pela base de dados em questão.

Peço desde já desculpa se o texto anterior estiver muito confuso...  😄 !

Grato pela ajuda!

Cumps!

😄

[pedrotuga]

Se toda a informação que te interessar guardar puder ser guardada na base de dados então não precisas de usar o serialize para nada. A questão é, quando fechas a aplicação, toda a informação que poderás precisar futuramente, está na base de dados?

[skcratch]

Viva!

Creio que já estou a perceber melhor... Tal como utilizo a interface Serializable de modo a persistir objectos no disco de forma binária(não percebo muito bem esta parte...) tenho que utilizar essa mesma interface para persistir os objectos também no ficheiro correspondente da base de dados.

Será assim, mais ou menos?

Cumps!

😄

[pedrotuga]

É mais simples do que tu pensas. Estás a fazer fé em frazes feitas que te disseram em vez de tentar perceber.

Esquece a palavra "persistencia".

Tens uma classe com uma carrada de atributos e queres que o teu programa guarde o estado em que ela está para a próxima vez que o usares. Como fazes? Guarda-la por exemplo num ficheiro. Mas como é que se guarda uma classe num ficheiro, uma class é um conjunto de bytes dispersos na memória, e em java nem sequer tens acesso aos endereços de memória das variáveis.

A solução é muito simples. Um serialize faz-te uma cópia da classe para uma sequencia de bits. Podes guardar esses bits num ficheiro. Pronto, já está. Depois quando quiseres recupera-la vais ao ficheiro, les o que lá está e 'des-serializas'.

E estás feliz.

As vezes podes não querer guardar um objecto  inteiro, em vez disso só precisas de dois ou três valores.... ainda mais simples, poe-nos num ficheiro no formato que te der mais jeito. Ou então guarda-os numa base de dados.

[Knitter]

Esse interface é que permite ao stream de leitura e escrita saber como escrever e ler os dados, embora a maioria das vezes esse interface apenas seja implementado e usado de forma genérica podes implementar os métodos do interface e dizer como queres que os dados sejam escritos e lidos.

Errado.

pq ao implementares essa interaface ficas com duas funcoes read e write (acho eu que sao estas funcoes) e sao essas duas funcoes que gravam e leem do disco 😁

Errado.

A interface Serializable não possui qualquer método nem diz a stream nenhuma como ler ou escrever dados. A interface não tem qualquer método nem te obriga a implementar qualquer método, é o que se chama uma interface de marcação ou um marcador.

A plataforma simplesmente não te deixa tentar serializar um objecto que não tenha essa interface na declaração da classe.

Embora seja da responsabilidade do programador dizer como é que a classe é serializada, só em casos muito especiais é que terás de implementar métodos para esse efeito. O mais comum será usares o mecanismo de serialização por omissão, que é obtido de uma stream do tipo ObjectOutputStream. Podes instanciar um ou usar o out.defaultWriteObject, que existe na stream de saída padrão, novamente o mais comum é instanciar um objecto do tipo ObjectOutputStream baseado num qualquer nome de ficheiro para onde pretendes guardar os dados.

(...)

Tens uma classe com uma carrada de atributos e queres que o teu programa guarde o estado em que ela está para a próxima vez que o usares. Como fazes? Guarda-la por exemplo num ficheiro. Mas como é que se guarda uma classe num ficheiro, uma class é um conjunto de bytes dispersos na memória, e em java nem sequer tens acesso aos endereços de memória das variáveis.

Nem é importante teres acesso à memória, a serialização por omissão escreve em formato binário no entanto podes escrever para qualquer formato, desde simples texto a XML. Embora isso implique um conhecimento muito grande de como funcionam as classes e o sistema de loading de classes, não é coisa simples 😄

(...)

As vezes podes não querer guardar um objecto  inteiro, em vez disso só precisas de dois ou três valores.... ainda mais simples, poe-nos num ficheiro no formato que te der mais jeito. Ou então guarda-os numa base de dados.

Se não te interessa guardar tudo indica quais os valores que não são guardados, marcando-os como transient. O mecanismo de serialização por omissão guarda todos os campos que implementem a interface Serializable e todos os tipos primitivos que não estejam marcados como  transient.

É preciso ter atenção que objectos compostos, objectos que contenham outros objectos, precisam que todos os seus atributos sejam serializáveis, ou o sistema vai abortar a serialização, podendo lançar ou não uma excepção. Este é um pormenor que por vezes atrapalha quando se está a começar a usar a serialização: a excepção é engolida no meio de um método ou output qualquer e nunca é vista pelo programador. Resultado, estamos a ver um código que não dá erros mas não conseguimos fazer o processo inverso da serialização, não conseguimos voltar a ler um ficheiro para onde serializamos um objecto.

Dois outros pormenores que vale a pena indicar, a serialização é um processo que transforma uma classe completa e a guarda, isto implica que se serializares uma instância de uma classe e mais tarde acrescentares um método ou atributo, ou alterares a assinatura de qualquer método dentro dessa classe, a intância serializada deixa de poder ser recuperada. Isto é, a serialização não é retro-compatível com versões diferentes do mesmo objecto. Não é possível reverter a serialização de um objecto cuja classe tenha sofrido alterações.

Segundo, se serializares mais que um objecto para um ficheiro, e dado que estamos a trabalhar com um sistema que, na sua versão por omissão, apesar de simples e poderoso, não oferece controlo sobre os ponteiros de leitura dos ficheiros, terás de ler os objectos pela ordem com que os introduziste. Isto é, a gravação de objectos tem início no princípio do ficheiro e é forward-only e a leitura também.

É comum serem colocados números de série, do tipo long, como atributos das classes a serializar, isso não é obrigatório, e para a maior parte dos casos não oferece vantagens, pelo menos que eu conheça.

Viva!

Creio que já estou a perceber melhor... Tal como utilizo a interface Serializable de modo a persistir objectos no disco de forma binária(não percebo muito bem esta parte...) tenho que utilizar essa mesma interface para persistir os objectos também no ficheiro correspondente da base de dados.

Será assim, mais ou menos?

Cumps!

😄

Não será comum teres os dois tipos de persistência (pedrotuga, tenho de lhe chamar o que é 😁), ou usas um ou usas outro, usar os dois só em casos particulares. Estou a lembrar-me por exemplo de uma aplicação que guarda os dados numa BD mas que guarda as propriedades da aplicação, o tamanho da janela, posição no ecrã, coisas simples e que se podem perder sem causar problemas, através da serialização.

Não serializas para a base de dados. Apesar de existirem BDs que permitem isso é um sistema ainda pouco compatível e que não trará vantagens.

Resumido, o sistema de serialização é um sistema simples que, usando os métodos por omissão, transforma o estado de um objecto numa sequênica de bytes. Permite também reverter o processo devolvendo assim uma nova instância com estado igual ao estado do objecto persistido.

Se quiseres exemplos de serialização avisa que posso colocar aqui um ou outro. Posso dizer que usei serialização em várias situações, guardar estados de jogos(save games), sistema de undo/redo, editores de texto, etc.

[skcratch]

Viva!

Creio que já percebi os conceitos fundamentais envolvidos mas mesmo assim ainda preciso de analisar melhor tudo aquilo que foi escrito.

Obrigado a todos pelos esclarecimentos.

Cumps!

😄

P.S.-> Caro Knitter, se quiseres disponibilizar uns exemplos (e respectivo contexto de utilização, se possível) eram sempre bem-vindos! 😄

[Knitter]

http://wiki.sergio-lopes.org/index.php?n=Projects.School2004-2005

Trabalhos de programação 4, J2Gether. Nesse, a serialização é usada para o sistema de undo/redo e para guardar os scores.