4.1 Costruttore
Builder è un modello di progettazione generativa che fornisce un modo per creare un oggetto composito.
Separa la costruzione di un oggetto complesso dalla sua rappresentazione in modo che lo stesso processo di costruzione possa portare a rappresentazioni diverse.
Punti di forza:
- permette di modificare la rappresentazione interna del prodotto;
- isola il codice che implementa la costruzione e la presentazione;
- offre un controllo più preciso sul processo di progettazione.
Lati deboli:
- l'algoritmo per la creazione di un oggetto complesso non dovrebbe dipendere dalle parti di cui è composto l'oggetto e da come si incastrano;
- il processo di costruzione deve fornire diverse rappresentazioni dell'oggetto che viene costruito.
Un buon esempio è la classe HttpRequest, che ha una sottoclasse HttpRequest.Builder che può essere utilizzata per creare istanze della classe HttpRequest e assicurarsi che siano valide.
4.2 Inizializzazione pigra
L'inizializzazione lazy è una tecnica di programmazione quando un'operazione ad alta intensità di risorse (creazione di oggetti, calcolo del valore) viene eseguita immediatamente prima che il suo risultato venga utilizzato.
Pertanto, l'inizializzazione viene eseguita "su richiesta" e non in anticipo. Un'idea simile trova applicazione in una varietà di aree: ad esempio, la compilazione al volo e il concetto di logistica Just-in-Time.
Un caso speciale di inizializzazione pigra - la creazione di un oggetto al momento dell'accesso - è uno dei modelli di progettazione generativa. Viene tipicamente utilizzato insieme a pattern come Factory Method, Loner e Proxy.
Punti di forza:
- L'inizializzazione viene eseguita solo quando è realmente necessaria;
- L'inizializzazione iniziale dell'applicazione viene accelerata: tutto ciò che può essere posticipato viene posticipato.
Lati deboli:
- Non è possibile impostare in modo esplicito l'ordine in cui gli oggetti vengono inizializzati;
- C'è un ritardo al primo accesso all'oggetto, che può essere critico quando un'altra operazione a uso intensivo di risorse viene eseguita in parallelo. Per questo motivo, è necessario considerare attentamente l'opportunità di utilizzare l'inizializzazione lazy nei sistemi software multithread.
Ricordi come quando scrivi web.xml potresti specificare l'ordine di inizio dei servlet lì? Questo è esattamente il risultato del caricamento lento. Tomcat creerà oggetti servlet al primo accesso.
4.3 Gruppo di oggetti
Un pool di oggetti è un modello di progettazione padre, un insieme di oggetti inizializzati e pronti per l'uso. Quando il sistema necessita di un oggetto, questo non viene creato, ma prelevato dal pool. Quando un oggetto non è più necessario, non viene distrutto ma restituito al pool.
Il raggruppamento di oggetti viene utilizzato per migliorare le prestazioni quando la creazione di un oggetto all'inizio di un lavoro e la sua distruzione alla fine è costosa. Il miglioramento delle prestazioni è particolarmente evidente quando gli oggetti vengono creati e distrutti frequentemente, ma ne esiste solo un piccolo numero contemporaneamente.
Un pool di oggetti è utile quando un oggetto possiede risorse diverse dalla memoria, come i socket di rete. Oppure se la raccolta di oggetti occupa una parte significativa della memoria del computer e si crea molta "spazzatura".
Come ricordi, Tomcat esegue ogni richiesta in un thread separato. Ma i thread non vengono creati ogni volta di nuovo, ma vengono archiviati nel pool di thread. Ciò consente un'esecuzione più rapida delle richieste: quando è necessario un thread, viene semplicemente prelevato dal pool. A proposito, la domanda è: come inseriresti il thread in esecuzione nel pool e lo prenderesti dal pool?