Composite



Scaricare 0.68 Mb.
Pagina3/7
03.04.2019
Dimensione del file0.68 Mb.
1   2   3   4   5   6   7

Pull model




Figura 14 b - diag14b.gif


Uno dei ConcreteObserver appartenenti alla lista dei Viewers richiama la SetState() della ConcreteSubject che ha la stessa funzione di prima.

La ConcreteSubject lancia la Notify() che anche nel caso del pull model ha la funzione di invocare la Update() di ogni ConcreteSubject nella lista dei Viewers. In questo caso, però, la Update() ha la funzione di notificare a tutti i ConcreteObserver della lista dei Viewers che è avvenuto un cambiamento dello stato della ConcreteSubject. A questo punto i ConcreteObserver interessati a conoscere nei dettagli tale cambiamento possono decidere di esserne messi al corrente invocando la GetState() della ConcreteSubject che ha la stessa funzione di prima.


Usando il pull model le classi diventano estremamente riusabili e non ci sono perdite di tempo dovute ad aggiornamenti inutili.

Tuttavia questo modello potrebbe essere inefficiente perché le classi Observers devono accertarsi di cosa è cambiato senza l’aiuto della Subject e questo potrebbe portare, come abbiamo già detto, all’inconsistenza dei dati.



Nota: il diagramma a classi del pattern è lo stesso nei due casi, quello che cambia è il diagramma dinamico e l’implementazione delle funzioni.

Il pattern Observer generico è il seguente:





Figura 15 - diag15.gif


NB: Un Observer potrebbe osservare più Subject diverse.

Esempio:

Consideriamo una rete di calcolatori suddivisa in più sottoreti locali.



Figura 16 - diag16.wmf

I messaggi che vengono scambiati tra i calcolatori devono passare attraverso i collegamenti fisici esistenti tra i calcolatori stessi.

Le tabelle di routing stabiliscono i percorsi fisici attraverso i quali far passare i messaggi per portarli dai mittenti ai destinatari. Queste tabelle vengono continuamente aggiornate in modo da far fronte ad eventuali aggiunte di nuovi nodi alla rete o a cambiamenti di percorso per evitare competizioni tra i nodi. Per scegliere i percorsi alternativi, le tabelle di routing dispongono anche di statistiche riguardanti i pacchetti che viaggiano sui canali.

I computer di collegamento tra LAN (Local Area Network) hanno anche informazioni sul traffico e sul routing dell’intera LAN su cui si trovano.

Supponiamo che esista un computer particolare che osserva il traffico e risistema le tabelle di routing.

Il problema è fare in modo che le tabelle di routing siano accessibili da più sistemi contemporaneamente, cioè siano condivise e consistenti in ogni momento, tenendo conto del fatto che possono essere modificate in qualunque istante.
Un possibile diagramma a istanze è il seguente:

Figura 17 - diag17.wmf

Il problema della composizione della rete viene risolto dal pattern Composite, mentre il problema della condivisione e della sincronizzazione della tabella di routing viene risolto dal pattern Observer.

La struttura dati che farà sviluppare gli observers a prescindere dai collegamenti esistenti fra i computer può essere la seguente:



Figura 18 - diag18.gif

Questa soluzione è un’ibridizzazione del pattern Observer e del pattern Composite.





Condividi con i tuoi amici:
1   2   3   4   5   6   7


©astratto.info 2017
invia messaggio

    Pagina principale