Java è certamente un punto di riferimento per la programmazione orientata agli oggetti e lo sviluppo di applicazioni Web. Tra le caratteristiche importanti del linguaggio ci sono i modificatori di accesso, che rendono possibili meccanismi come l'incapsulamento e non solo. I più famosi come public, protected e private, fanno parte dell'"abc" del linguaggio e appresi fin dai primi approcci, altri, meno noti, vengono utilizzati in particolari circostanze, come il modificatore d'accesso transient, che esaminiamo in questo articolo.
Si rende necessario definire una proprietà transient, esclusivamente quando facciamo uso di serializzazione, cioè quando convertiamo un oggetto in uno stream, in modo da poterne gestire la persistenza o la remotizzazione. Cerchiamo di capire cos'è e perché si usa.
transient private File fileAccessoDati;Attraverso la proprietà transient stiamo dicendo al compilatore che una certa variabile non deve essere serializzata. Molto semplice, in pratica il funzionamento è quello di sempre, solo che, all'atto della serializzazione, questa variabile viene saltata e quindi forzatamente posta a null.
Nota: Una variabile transient non può essere final o static.
I motivi per cui può presentarsi tale necessità sono in realtà limitati. Sicuramente quello di non sollevare eccezioni all'atto di serializzare una classe che presenta come variabili classe che non implementano l'interfaccia Serializable. Altro esempio si potrebbe avere per motivi di sicurezza, ossia definire transient una stringa (o altra classe) contenente una password che viaggia in rete. Molto più realistica è invece il suo uso nello sviluppo distribuito attraverso RMI e sue evoluzioni (EJB, per esempio) e nella persistenza di istanze di oggetti. Vediamo l'esempio che segue e cerchiamo di capire perché.
Un esempio concreto
Immaginiamo di dover sviluppare un EJB da eseguire in remoto, per esempio con la struttura di classi che segue:
class OggettoSerializzabile implements Serializable
{
// ...
public File f;
// ...
Public OggettoSerializzabile(String filename)
{
f = new File(filename);
}
}
@Stateless
@Remote
class StatelessRemote implements StatelessBean
{
public void metodoCheUsaIlFile(OggettoSerializzabile os;)
{
//...
//leggi il file
FileInputStream fis = new FileInputStream (os.f);
//...
}
}Abbiamo un oggetto POJO, la classe OggettoSerializzabile e la classe che gestisce la logica di business StatelessRemote, che ha una variabile di istanza di tipo OggettoSerializzabile.
Immaginiamo di mettere tutto in un reale ambiente di produzione e per un momento dimentichiamo che la serializzazione di OggettoSerializzabile ci restituirebbe un errore perché File non è serializzabile. Cosa accadrebbe? Il client dovrebbe istanziare un OggettoSerializzabile con un file concreto, ad esempio:
//...
OggettoSerializzabile ogg = new OggettoSerializzabile ("c:/file.txt");
//...
statelessLogic.metodoCheUsaIlFile(ogg);
//...Il client sta instanziando un oggetto puntando ad una risorsa fisica, un file, che si trova ad una data posizione in concreto sull'hard disk del client. La classe remota (l'ejb) proverebbe ad eseguire il metodo cercando di accedere ad una risorsa che su quella macchina non esiste!
Ecco quindi spiegato perché per poter far funzionare il tutto avremmo dovuto definire come transient la proprietà f (il File) della classe POJO e gestire in maniera completamente distinta la logica di accesso ai dati (magari con una lettura preventiva lato client).
Conclusioni
In generale con questo esempio abbiamo voluto mostrare l'uso per eccellenza del modificatore transient, cioè quando abbiamo a che fare con risorse fisiche (file, connessioni a database, etc.) e oggetti che vengono distribuiti su diversi nodi per l'esecuzione di logica di business.
A mio avviso, in realtà, tale modificatore non dovrebbe essere mai utilizzato. Nel senso che lo sviluppo dovrebbe seguire altre strade, per esempio gestire le risorse fisiche in maniera diversa e realizzare lo scambio di oggetti esclusivamente contenitore. In questo caso avremmo dovuto pensare ad una classe manager che si occupasse della lettura delle informazioni, la creazione di un oggetto con tali informazioni e in seguito la serializzazione verso destinazioni remote. Ovviamente la realtà è spesso più complessa, ma un buon approccio allo sviluppo e l'uso corretto di questo modificatore d'accesso risolverà eventuali problemi di serializzazione.
