Introduzione
La discussione che segue affronta due temi: le argomentazioni legate al preservare l'incapsulamento dello stato di un oggetto e quelle relative all'uso e applicabilità di Oggetti Immutabili. Verranno espressi alcuni accorgimenti di design e di programmazione atti a sviluppare entrambe le tematiche.
Problemi dell'Accesso Controllato
Lo sviluppatore ad Oggetti è consapevole dell'importanza dei metodi di accesso per proteggere lo stato "privato" di un elemento: il software di oggi vede un'abbondante presenza di forme di questo tipo:
public class MyObject
{ private String name = ...
private HashMap properties = ...
...
public String getName()
{ return n;
}
public HashMap getProperties()
{ return p;
}
public void setName(String n)
{ this.n = n;
}
public void setProperties(HashMap p)
{ this.p = p;
}
...
}
Questa idea viene rafforzata da alcune specifiche, nei differenti linguaggi, che fanno della naming convention sui Getter/Setter la base per la capacità di esplorare componenti di cui non si conosce il sorgente, come nel caso dei JavaBean!
La realizzazione dell'incapsulamento in questo modo è immediata ma presenta dei limiti con un oggetto non più banale:
- la presenza di una coppia di metodi per ogni proprietà porta al proliferare di codice rendendo l'oggetto FAT!
- Se le proprietà di un oggetto non sono solo primitivi, i semplici metodi di accesso possono risultare inutili: riprendendo il codice appena letto, l'attributo PROPERTIES può essere tranquillamente corrotto dall'esterno nonostante i Get/Set...Si presenta come se fosse stato dichiarato pubblico!
Chi vieta, infatti, un'azione del tipo:
myObjectInstance.getProperties().put("IMPORTANT_ATTR", WRONG_VALUE);
senza quindi utilizzare un opportuno Setter?!?!
Proteggiamo lo stato di un Oggetto: Defensive Copy e Oggetti Immutabili
Una semplice soluzione alla problematica appena emersa consiste nell'azione di copia o cloning degli elementi di stato. Quello che viene proposto è una tecnica secondo la quale nei metodi di GET viene ad essere restituito non il vero attributo ma una sua copia:
public HashMap getProperties()
{ return p.clone(); // oppure return new HashMap(p);
}
Quanto esposto rimane valido anche se, invece di considerare un singolo attributo, prendiamo in esame l'intero stato di un oggetto, a sua volta espresso come istanza di una specifica classe:
public class MyObjectStatus
{ ...
}
public class MyObject
{ private MyObjectStatus instanceStatus = ...
...
public MyObjectStatus getObjectStatus()
{ return instanceStatus.clone();
}
...
}
La tecnica di
defensive copy anche in questo caso ci protegge da un un uso improprio dello stato di un oggetto!
Questa idea sembra del tutto funzionale, ma è facile evidenziarne alcuni difetti:
- si determina la creazione di molti oggetti temporanei e, su un numero sensibile di attributi, il processo potrebbe divenire dispendioso in termini di memoria
- l'attività di cloning può risultare problematica se l'oggetto da clonare è complesso: questo generalmente è evidente quando lo stato di un oggetto è espresso da strutture dati ricorsive o annidate ad N livelli.
- legato alla correttezza del Design, vi è un altro aspetto. La forma utilizzata per l'attributo PROPERTIES pone in evidenza che il nostro Oggetto usa una data tipologia di mappa come proprio "internal": lì dove è possibile, è preferibile evitare che un metodo suggerisca il COME di un'astrazione, discorso questo che risulta importante se si decide di variare il tipo di ritorno del Getter e se la nostra astrazione è la root-class di una gerarchia(vedesi il problema: fragilità della classe base)!
Quanto detto può portarci a formulare il precedente metodo nella forma:
public Map getProperties()
{ return p.clone(); // oppure return new HashMap(p);
}
Un altro approccio per preservare lo stato del nostro Oggetto è quello di renderlo immutabile: un'astrazione in sola lettura dovrebbe permettere di avere degli elementi consistenti nel tempo ed essere, per sua natura, condivisibile e thread-safe!
Questa idea è molto diffusa ed è punto di discussione in molte realizzazione: basti pensare alla controversa natura degli oggetti String in Java.
Un Oggetto Immutabile è formulato generalmente con la sola presenza di metodi di GET ed un costruttore che permette il setup dei valori delle variabili di stato altrimenti non attribuibili; a volte i costruttori sono più di uno: in alcuni casi si preferisce fornire un COPY CONSTRUCTOR che permette di ottenere un Oggetto Immutabile da un altro per copia.
Supponiamo di avere un Oggetto Immutabile che presenta la forma:
public class MyObject
{ private final String n;
private final Map p;
public MyObject(String n, Map p)
{ this.n = n;
this.p = p;
}
public MyObject(MyObject mo)
{ this.n = mo.getName();
this.p = mo.getProperties();
}
public String getName()
{ return n;
}
public Map getProperties()
{ return p.clone();
}
}
Esaminiamo ora un possible uso pericoloso da parte di un altro sviluppatore:
Map m = new HashMap();
MyObject obj = new MyObject("DEMO", m);
...
m.put("IMPORTANT_ATTR", WRONG_VALUE);
Notiamo che, anche se l'oggetto è immutabile, lo stato può essere ancora una volta corrotto!
È possibile, anche in questo caso, lavorare in "modo difensivo" è rafforzare il costruttore attuando una copy dei parametri complessi in ingresso:
MyObject(String n, Map p)
{ this.n = new String(n);
this.p = new HashMap(p);
}
Il nuovo costruttore fa sì che il codice scritto dal developer di terze parti, così come esposto prima, non abbia influenza sullo stato del nostro oggetto.
L'opportuna costruzione di un Oggetto Immutabile può essere resa più comoda e validante grazia all'adozione di una factory: un metodo dedicato permetterà di nascondere le problematiche creazionali permettendo pre-processamenti e controlli prima dell'effettiva definizione del nuovo oggetto. Riprendendo il nostro esempio possiamo ipotizzare allora del codice nella forma:
public class MyObject
{ private final String n;
private final Map p;
private MyObject(String n, Map p)
{ this.n = n;
this.p = p;
}
public static MyObject newObject(String arg1, Map arg2)
{ String stringToPass = new String(arg1);
Map mapToPass2 = new HashMap(arg2);
return new MyObject(stringToPass, mapToPass);
}
...
}
Questa idea può essere estesa fino ad arrivare ad una factory-class(Mutable Companion Pattern) che permetta di simulare la presenza di Setter pur continuando a lavorare con oggetti immutabili:
public class MyObjectCompanion
{ private final String stringArg;
private final Map mapArg;
public synchronized void setArgs(String data, Map map)
{ stringArg = data;
mapArg = map;
}
public synchronized MyObject toObject()
{ return new MyObject(stringArg, mapArg);
}
...
}
Riportiamo ora delle semplici linee guida che permettono di definire Oggetti Immutabili:
- dichiarare la classe FINAL
- dichiarare tutti gli attributi PRIVATE
- dichiarare solo QUERY METHOD, cioè solo GETTER
- dichiarare dei costruttori per l'inizializzazione dei dati
Queste linee guida possono essere completate da una serie di accorgimenti che determinano un enforcing della particolare natura dell'oggetto:
- dichiarare tutti gli attributi anche FINAL
- non usare il riferimento a THIS del costruttore
- non restituire oggetti mutabili: usare la tecnica del defensive copy o restituire solo oggetti a loro volta immutabili
Usare gli Oggetti Immutabili
L'uso di oggetti immutabili ha sicuramente dei grossi limiti ed è, quindi, necessario valutare quando adottarli. Per loro natura, questi elementi sono ottimi quando l'obiettivo è la condivisione di valori e la loro dimensione è limitata: lo sharing di risorse nasce per migliorare il consumo di memoria allorché si evidenzi l'adozione di Oggetti Valore, come Date, Unità di Misura e simili, nel proprio sistema. È possibile distinguere due tipologie di resource-sharing:
extrinsic-sharing e
intrinsic-sharing.
Extrinsic Sharing
Adottando questa soluzione, l'utente non può creare direttamente un oggetto immutabile ma dovrà ricorrere ad un factory-method che prenderà in ingresso un dato token. All'interno della classe verrano mantenuti dei riferimenti agli oggetti creati in modo da riutilizzare le risorse già richieste: un nuovo oggetto verrà ad essere istanziato solo se non presente nella mappa gestita dalla classe dell'oggetto immutabile. In questo approccio l'identità dei diversi oggetti immutabili è preservata, mettendo in evidenza che l'oggetto richiesto, a parità di token immesso, è condiviso!
Vediamo del codice d'esempio:
public class MyObject
{ private static Set instances = new HashSet();
private final String stringArg;
private final Map mapArg;
private MyObject(String n, Map p)
{ stringArg = n;
mapArg = p;
}
public static MyObject get(String data, Map map)
{ MyObject result = null;
for (Iterator iter = instances.iterator(); iter.hasNext();) { MyObject tmp = (MyObject)iter.next();
if (tmp.stringArg.equals(data) && tmp.mapArg.equals(map)) { result = tmp;
break;
}
}
if (result == null) { result = new MyObject(data, map);
instances.add(result);
}
return result;
}
...
}
Un esempio d'uso potrebbe essere il seguente:
String name="Pippo";
Map context = new HashMap();
// Pippo viene creato...
MyObject first = MyObject.get(name, ctx);
// Pippo viene estratto dall'insieme delle istanze
MyObject second = MyObject.get(name, ctx);
first == second // TRUE...
Intrinsic Sharing
In questo approccio l'utilizzatore dell'oggetto immutabile può creare elementi con il classico "new" ma all'interno della classe verrà mantenuto l'insieme degli stati dei differenti oggetti: saranno questi stati ad essere condivisi; da ciò il nome di intrinsic-sharing. Gli oggetti creati hanno, a differenza del primo design, differente identità.
public class MyObject
{ private static Set internals = new HashSet();
private MyObjectInternal internal;
private static class MyObjectInternal
{ private String stringArg;
private Map mapArg;
MyObjectInternal(String n, Map m)
{ stringArg = n;
mapArg = m;
}
}
public MyObject(String data, Map map)
{ internal = get(data, map);
}
private static MyObjectInternal get(String data, Map map)
{ MyObjectInternal result = null;
for (Iterator iter = instances.iterator(); iter.hasNext();)
{ MyObjectInternal tmp = (MyObjectInternal)iter.next();
if (tmp.stringArg.equals(data) && tmp.mapArg.equals(map)) { result = tmp;
break;
}
}
if (result == null) { result = new MyObjectInternal(data, map);
instances.add(result);
}
return result;
}
public String getStringArg()
{ return internal.stringArg;
}
...
}
Un esempio d'uso potrebbe essere il seguente:
String name="Pippo";
Map context = new HashMap();
...
MyObject first = new MyObject(name, context);
MyObject second = new MyObject(name, context);
first == second //FALSE
Conclusioni
Gli oggetti immutabili sono dei tool interessanti anche se in apparenza possono sembrare estremamente limitati. Sono presenti spesso nella programmazione concorrente e in quella, immediatamente affine, ad eventi: un Event Object è frequentemente realizzato come oggetto immutabile posto su un'apposita coda.
Termino questo articolo proponendovi una riflessione sulle possibilità di evidenziare le parti immutabili di un oggetto e con un quesito: Qual è il G.o.F. pattern correlato all'uso della tecnica di extrinsic-sharing?
Discuti sul forum
Stampa
![[LM]](../../../images/skin/default/icons/lm_sm.png){kind=icon}
.
Made with GIMP
& WPP.