Teoria di Ingegneria del software

RAM.Soluzione

Tutto ciò che è statico lo memorizzo una volta sola, tutto ciò che invece cambia da un'occorrenza all'altra lo memorizzo più volte.

Dove si usa questo Pattern?

Solo quando il programma deve supportare un numero enorme di oggetti che si adattano a malapena alla RAM disponibile.

PRO:

• Si può risparmiare molta RAM.

CONTRO:

• Il risparmio della RAM avviene a spese dei cicli di CPU.
• Il codice diventa molto più complicato.

PROXY

Intent

Consente di fornire un sostituto o un segnaposto per un altro oggetto. Un proxy controlla l'accesso all'oggetto originale, consentendo di eseguire qualcosa prima o dopo che la richiesta arriva all'oggetto originale.

Problema

Supponiamo di avere un oggetto massivo che consuma una grande quantità di risorse di sistema. Ne abbiamo bisogno di tanto in tanto, ma non sempre. Si potrebbe implementare una inizializzazione pigra: in questo caso si creerebbe questo oggetto solo

quando è effettivamente necessario.

Soluzione

Il pattern suggerisce di creare una nuova classe proxy con la stessa interfaccia di un oggetto di servizio originale. A questo punto si può aggiornare la nostra applicazione in modo che passi l'oggetto proxy a tutti i client dell'oggetto originale. Al ricevimento di una richiesta da parte di un client, il proxy crea un oggetto di servizio reale e delega ad esso tutto il lavoro. Un esempio è il dottore con la segretaria, che rappresenta il proxy, che svolge il grosso delle mansioni.

Dove si usa questo Pattern?

• Inizializzazione pigra (proxy virtuale).
• Controllo degli accessi (proxy di protezione).
• Esecuzione locale di un servizio remoto (proxy remoto).
• Richieste di jogging (proxy di logging).

PRO:

• Si può risparmiare molta RAM.

CONTRO:

• Il risparmio della RAM avviene a spese dei cicli di CPU.
• Il codice diventa molto più complicato.

PATTERN COMPORTAMENTALI

CHAIN

OF RESPONSABILITY

Intent

Consente di passare le richieste lungo una catena di gestori. Al ricevimento di una richiesta, ogni gestore decide di elaborare la richiesta o di passarla al successivo gestore della catena

Problema

Supponiamo di lavorare a un sistema di ordini online, vogliamo limitare l'accesso al sistema in modo che solo gli utenti autenticati possano creare ordini. Inoltre, gli utenti che hanno autorizzazioni amministrative devono avere pieno accesso a tutti gli ordini. E quindi il sistema deve fare dei controlli che avvengono in sequenza.

Soluzione

Il pattern suggerisce di creare dei particolari gestori chiamati handler e collegati tra loro come una catena. Se c'è qualcosa che non va l'handler mi butta fuori dalla catena. Questa catena potrebbe essere o lineare o inserita in un albero.

Dove si usa questo Pattern?

• Quando il nostro programma deve elaborare diversi tipi di richieste in vari modi, e che non sono note in anticipo.
• Quando bisogna

eseguire diversi gestori in un particolare ordine.

PRO:

• E' possibile controllare l'ordine di gestione delle richieste.
• Principio della responsabilità unica.
• Principio aperto/chiuso.

CONTRO:

• Alcune richieste possono terminare senza essere eseguite.

COMMAND

Intent

Trasforma una richiesta in un oggetto a sé stante che contiene tutte le informazioni sulla richiesta. Questa trasformazione consente di parametrizzare i metodi con diverse richieste, ritardare omettere in coda l'esecuzione di una richiesta e supportare le operazioni annullabili.

Problema

Supponiamo di lavorare a un text editor. Il nostro compito è quello di creare una barra degli strumenti con una serie di pulsanti per le varie operazioni dell'editor. Avremo quindi una serie di bottoni simili che rappresentano ognuno un'azione diversa.

Soluzione

Il pattern suggerisce di, invece di creare molte sottoclassi, metto un'oggetto Command (che contiene i dettagli

Il tuo compito è formattare il testo fornito utilizzando tag html.

ATTENZIONE: non modificare il testo in altro modo, NON aggiungere commenti, NON utilizzare tag h1;

della richiesta) tra la User Interface e il server.

Dove si usa questo Pattern?

• Quando desideriamo parametrizzare gli oggetti con le operazioni.
• Quando vogliamo mettere in coda le operazioni, pianificare la loro esecuzione o seguirle in remoto.

PRO:

• Principio della responsabilità unica.
• Principio aperto/chiuso.

CONTRO:

• Il codice può diventare più complicato.

ITERATOR

Intent

Permette di attraversare gli elementi di una collezione senza esporne la rappresentazione sottostante (lista, pila, albero).

Problema

Supponiamo di avere una collezione, ovvero un contenitore per un gruppo di oggetti. Devo trovare un modo per trovare un oggetto in modo efficace ed efficiente.

Soluzione

Il pattern suggerisce di estrarre il comportamento di attraversamento di una collezione in un oggetto separato chiamato iteratore.

Dove si usa questo Pattern?

• Quando la nostra collezione ha alla base una struttura dati complessa, ma vogliamo nasconderne la complessità

ai client.

• Per ridurre la duplicazione del codice di attraversamento nella nostra applicazione.

PRO:

• Principio della responsabilità unica.
• Principio aperto/chiuso.

CONTRO:

• Applicare il pattern può essere un'esagerazione se la collezione è semplice.

MEDIATOR

Intent

Consente di ridurre le dipendenze caotiche tra gli oggetti. Il pattern limita le comunicazioni dirette tra gli oggetti e li costringe a collaborare solo attraverso un oggetto mediatore.

Problema

Supponiamo di dover mettere in comunicazione due database. Tuttavia ogni database ha un proprio significato, serve perciò un mediatore/traduttore che metta in relazione la stessa voce tra i due database diversi. E quindi si fa un'integrazione tra i due database in un unico database.

Soluzione

Il pattern suggerisce di interrompere ogni comunicazione diretta tra i componenti che si desiderano rendere indipendenti l'uno dall'altro. Questi componenti devono invece

PRO:

• Principio della responsabilità unica.
• Principio aperto/chiuso.
• Si riduce l'accoppiamento tra i vari componenti più facilmente.

CONTRO:

• Un mediatore può evolvere in un oggetto onnipotente.

MEMENTO

Intent

Permette di salvare e ripristinare il stato precedente di un oggetto senza rivelare i dettagli della sua implementazione.

Problema

Supponiamo di voler creare un'applicazione per l'editor di testi. Oltre alla semplice modifica, vogliamo che gli utenti possano annullare le operazioni effettuate sul testo (Il cosiddetto CTRL+Z).

Soluzione

Il pattern suggerisce di memorizzare la copia dello stato dell'oggetto in un oggetto speciale chiamato memento. Il contenuto del memento non è accessibile a nessun altro oggetto se non a quello che lo ha.

prodotto.Dove si usa questo Pattern?

• Quando desideriamo produrre snapshot dello stato di un oggetto per poter ripristinare un suo stato precedente.
• Quando l'accesso diretto ai campi/oggetti/impostazioni dell'oggetto ne viola l'incapsulamento.

PRO:

• A ogni istante posso tornare indietro.

CONTRO:

• Si consuma molta RAM se i client creano i memento troppo spesso.

OBSERVERIntent

Permette di definire un meccanismo di sottoscrizione per notificare a più oggetti gli eventi che accadono all'oggetto che stanno osservando.

Problema

Supponiamo di voler comprare il nuovo modello di iPhone che ancora deve uscire. Una soluzione sarebbe quella di recarsi ogni giorno al negozio per chiedere se è arrivato, altrimenti una soluzione più efficace è che il negozio quando esce il nuovo iPhone comunica a tutti i clienti che è uscito. Anche se questo è più dispendioso perché utenti non interessati potrebbero ricevere

questa comunicazione per loro inutile. Una soluzione ancora migliore è che i clienti interessati si registrano alla newsletter, gli altri no.

Soluzione

Il pattern suggerisce di creare 2 oggetti: uno si chiama Publisher (è quello che mette a disposizione in opportune liste delle informazioni), l'altro è il Subject (che deve interessarsi o meno a quelle liste).

Dove si usa questo Pattern?

• Quando le modifiche allo stato di un oggetto possono richiedere la modifica di altri oggetti.
• Quando alcuni oggetti della nostra app devono osservare altri.

PRO:

• Principio aperto/chiuso.

CONTRO:

• I subscribers vengono notificati in ordine casuale.

STATE

Intent

Permette ad un oggetto di modificare il suo comportamento quando il suo stato interno cambia.

Sembra che l'oggetto abbia cambiato la sua classe.

Problema

Ogni oggetto può trovarsi in vari stati. Il numero di stati di un oggetto è finito (concetto di macchina a stati finiti). Supponiamo di

essi in una classe separata edi rendere i loro oggetti intercambiabili.

Problema

Supponiamo di avere un'applicazione che ci conduca in un luogo. Per arrivarci ci sono 3 possibilità (bicicletta, autobus, taxi), ognuna con costi e tempi diversi. A seconda delle situazioni che possono crearsi posso prendere decisioni diverse. Supponiamo che si vogliano aggiungere dei mezzi e dei nuovi percorsi, questo potrebbe creare delle complicazioni.

Soluzione

Il pattern suggerisce di collegare anche qui la classe Navigator con un'interfaccia, e poi ogni tipologia di interfaccia diventa una classe.