Oggetti immutabili

Anni fa, secoli in termini informatici, esisteva il BASIC.
Il BASIC aveva un comando assai comodo: il GOTO che faceva saltare l'esecuzione del programma in un altro punto. Chiunque avesse studiato l'Assembly era abituato alle istruzione di Jump e non si vedeva niente di strano a fare salti con il GOTO.
L'abuso del GOTO portava a programmi per i quali era quasi impossibile seguire chiaramente il flusso di esecuzione del codice e si coniò un termine per quello stile di programmazione : "Spaghetti Code" per via del  groviglio che assumeva il flusso delle istruzioni, che in condizioni ideali, dovrebbe essere il più lineare possibile, per facilitare la leggibilità e la comprensione del programma.

Divenne comunemente accettato nella pratica della programmazione bandire il GOTO e "condannare" chi ne faceva uso come cattivo programmatore.
Più volte nella storia della programmazione si è considerata cattiva pratica qualcosa che fino a prima sembrava la cosa più normale del mondo.
Sono stati oggetto di ostracismo le stored procedure, la programmazione procedurale, la programmazione non cross platform ecc...

Oggi la diffusione sempre maggiore di macchine con ottime capacità di lavoro in parallelo e a basso costo, ha costretto a riconsiderare alcune pratiche di programmazione, che creano problemi in questi nuovi scenari.
Poter cambiare i valori delle proprietà di un oggetto in un contesto multithread, per esempio, è pericoloso perché ci espone al rischio che ci sia un accesso concorrente di più thread alla stessa risorsa, con blocchi o risultati difficilmente prevedibili.

Una delle strategie più recenti per difendersi da questi problemi, è semplicemente rendere gli oggetti immutabili, cioè non si deve permettere la modifica di un oggetto dopo la sua creazione e bisogna ricorrere alla creazione di un oggetto nuovo con i nuovi valori, che andrà a sostituire il vecchio.

Di sicuro non è un approccio che favorisce le prestazioni, però in effetti bisogna ammettere che evitare i rischi del multithreading è allettante.

Detto questo, ci sono casi nei quali un oggetto immutabile è semplicemente impossibile, per esempio una maschera dove i bottoni sono abilitati o disabilitati a seconda dello stato dell'applicazione, mi sembra la dimostrazione che in pratica un approccio così totalizzante, come evitare SEMPRE le classi mutabili, non sia possibile.

Un altro possibile approccio è quello usato dagli application server Java, dove la specifica proibisce ai programmatori delle web app di usare i thread, perché l'application server fornisce gli strumenti per far girare il codice in parallelo, senza ricorrere direttamente ai thread.

E' senza dubbio un'altra strategia difensiva, purtroppo però non è pensabile che ci sia sempre un application server sotto alla nostra applicazione, quindi non è una ricetta universale.