Vediamo oggi brevemente un'altra tecnica per la creazione di oggetti in Java: i Builder.
Abbiamo già visto nell'articolo precedente come in linguaggi C-like come Java manchino i nomi nei parametri passati nelle chiamate.
Questo diventa un problema nella leggibilità del codice soprattutto nei costruttori, dove oltretutto siamo obbligati a specificare soltanto un nome di metodo uguale al nome della classe.
I metodi factory presentati la volta scorsa non risolvono il problema dei nomi dei parametri e con il crescere del numero di parametri da passare, la difficoltà di comprensione e lettura del codice può solo peggiorare.
Il Builder Pattern risolve questo problema definendo una classe la quale mantiene internamente i parametri sia obbligatori che facoltativi che saranno da passare poi al costruttore vero della classe per la quale si desidera creare un'istanza.
La classe Builder deve avere dei metodi con un nome significativo per ciascun parametro da passare.
Un metodo "build" della classe builder stanzia la classe, passando i parametri valorizzati con i metodi dei quali scrivevo prima.
Si potrebbe obiettare che è sufficiente chiamare un costruttore senza parametri e poi usare dei metodi setter per passare i parametri. Purtroppo però questo presenta un altro svantaggio: usando i metodi setter non c'è un unico punto dove si può fare la validazione, cioè se diversi parametri devono concorrere per un criterio, che stabilisca la validità della creazione di un oggetto, è quasi impossibile verificare tale criterio, se i parametri sono passati con diversi metodi "set".
Il builder con il metodo "build" può concentrare il processo di validazione in un unico punto.
Inoltre JavaBeans, suggerendo di usare dei metodi setter, rende impossibile creare una classe immutabile, che oggi più che mai è importante, visto che l'hardware con il processori multi core a basso costo permette sempre di più di avere programmi con parti che girano in parallelo.
In Java l'abstract factory è realizzato dal metodo newInstance dell'oggetto Class. Purtroppo però newInstance chiama un costruttore senza parametri, con le limitazioni già discusse.
Anche per questi consigli e per vedere un esempio, si faccia riferimento all'ottimo Effective Java di Joshua Bloch.
A differenza di Bloch però, mi permetto di notare che è meglio non ricorrere a classi Builder statiche, proprio per potere usare i builder anche in ambienti multi thread, dove le parti statiche sono una fonte di problemi...
Nessun commento:
Posta un commento