L'observer pattern e' probabilmente uno dei piu' utilizzati patterns, almeno implicitamente. L'implementazione del pattern e' sempre piu' o meno la medesima, a differenza di .NET che sfrutta appieno il concetto di evento, come si evice dal seguente articolo.

Non sto a ripetere i concetti, i quali sono piu' che esaustivi negli articoli linkati. Sono piuttosto interessato a ragionare sulla scelta di implementazione fra eventi o classi (implementazione classica) nell'ottica delle performances. Senza dubbio l'implementazione con gli eventi .NET e' piu' elegante e necessita di meno codice. Dal punto di vista delle performance invece la soluzione ad eventi e' penalizzante.

Proviamo ad immaginare uno scenario nel quale il metodo notify impiega 2 secondi per essere eseguito. Bene, se utilizziamo l'approccio ad eventi ed abbiamo 4 sottoscrittori (observer) il tempo richiesto per eseguire notifyObservers (tutti i 4 notify) sara' di circa 8 secondi (qualcosa di piu', ma va bene lo stesso).

Usando l'approccio classico, abbiamo la possibilita' di effettuare delle chiamate asincrone all'interno della notifyObserver (ricordiamoci di usare WaitHandle.WaitAll prima di uscire) riducendo cosi' drasticamente il tempo totale di esecuzione del metodo notifyObservers (poco meno di 4 secondi).

Nella peggiore delle ipotesi (un solo sottoscrittore/observer), il tempo di esecuzione sara' identico fra i due approcci.

Morale, quando decidiamo di adottare un pattern e' bene tenere in condierazione le performance sin dalla fase di design, per evitare di arrivare alla fine e scoprire che abbiamo colli di bottiglia qua e la...