View Full Version : Introduzione Observer Pattern
ho già accennato l'idea nel thread "Refactor This!", magari è meglio parlarne a parte per poter rendere più visibile il problema e poterlo analizzare meglio. Partendo dal presupposto che sono un sostenitore dell'observer pattern:D credo sia la soluzione a molti problemi in diamonds, in particolare in tutti i casi in cui un oggetto interroga un altro oggetto sul suo stato interno (vedi metodi isXxx) si può far si che sia quest'ultimo a dire al primo quando cambia il suo stato, rendendo la cosa molto più lineare a mio avviso. Pareri a riguardo?
http://i27.tinypic.com/2rffvhv.gif
Io sono un sostenitore del codice semplice :)
http://i27.tinypic.com/2rffvhv.gif
Io sono un sostenitore del codice semplice :)
beh...secondo me mo lo semplifica il codice:D
Magari fai un esempio di use case dove il codice diventerebbe piu` semplice :P
beh...secondo me mo lo semplifica il codice:D
cisc, un intero Observer Pattern per togliere un metodo (isTransforming) mi sembra giusto un briciolo over engineering :)
Magari fai un esempio di use case dove il codice diventerebbe piu` semplice :P
StoneTurnState IsTransformingIteration Droppable
grid.runIteration(iteration)--------->droppable.isTransforming()---->
<-----------------------------------false
grid.runIteration(iteration)--------->droppable.isTransforming()---->
<-----------------------------------false
grid.runIteration(iteration)--------->droppable.isTransforming()---->
<-----------------------------------false
grid.runIteration(iteration)--------->droppable.isTransforming()---->
<-----------------------------------false (hai rotto i coglioni, sono una Gem io!!!)
StoneTurnState Stone
morphingGemCounter++<--------------------------------------stoneObserver.notifyTransformation(Transformation.STONE_TRANSFORMATION);
scusa, è un activity...ma rende l'idea:stordita:
cisc, un intero Observer Pattern per togliere un metodo (isTransforming) mi sembra giusto un briciolo over engineering :)
Beh no dai..non esageriamo adesso...a parte che non si tratta di implemetare un intero observer pattern, ma anche solo una parte, cmq non si toglierebbe solo isTransforming, anche isFalling e in generale tutta la struttura di iterazione delle droppable in Grid (o una buona parte)
anche se mi rendo conto che forse è un po prematuro come refactoring:stordita:
Se posso dire due parole: sarebbe bellissimo usare il dp Channel. Oltre che a risolvere la faccenda sopra ne risolverebbe tante altre, ad esempio sarebbe spettacolare per le catene di crash e per il calcolo dei punteggi. Inoltre abbinato al pattern state nei droppable permetterebbe ad ogni cambio di stato di registrarsi per essere notificato solo con determinati messaggi.
E' la combinazione del design pattern Observer e del design pattern Mediator, da come me l'avevano spiegato nel corso di ing del software (ci sta anche che sia un nome di comodo, era una cosa alquanto fumosa da quanto mi ricordo) in pratica è un canale di comunicazione fra consumatori e produttori che li disaccoppia completamente.
Esiste un unico canale e i consumatori si registrano presso il canale per un determinato evento, i produttori inviano l'evento sul canale. Il canale non fa altro che fare da dispatcher degli eventi verso i consumatori registrati per quell'evento.
Ad esempio: in caso di crush di un dato colore la gemma che crusha invia un evento di tipo Crush che conterrà anche la posizione della gemma. Tutte le gemme saranno registrate per l'evento Crush e riceveranno l'evento Crush, ovviamente una gemma alla ricezione avvia un altro Crush solo se la gemma che ha scatenato l'evento è del suo stesso colore e si trova accanto a lei.
In questo modo si sposta responsabilità della logica sui droppable, poi chiaro che abbinato ad un pattern State la cosa si farebbe ancora interessante, rendendo il droppable sensibile ad un determinato tipo di eventi a seconda del suo stato e cambiandone il comportamento di conseguenza.
Certo mi rendo conto che sarebbe un lavorone inserirlo adesso, ma secondo me sarebbe bello.
Per me il vero punto e': sono piu' le volte che dobbiamo cheidere qualcosa a tutte le gemme o piu' le volte che ci interessano solo alcune??
In ogni caso a me l'idea del dp channel piace!
(e comunque su wikipedia il dp channel non c'e' ... il che vuol dire che non esiste :asd: :asd: )
L'unica cosa che ho trovato e' questo articolo http://www.ddj.com/cpp/184401345
che ovviamnete non ho letto :D
Per me il vero punto e': sono piu' le volte che dobbiamo cheidere qualcosa a tutte le gemme o piu' le volte che ci interessano solo alcune??
In ogni caso a me l'idea del dp channel piace!
(e comunque su wikipedia il dp channel non c'e' ... il che vuol dire che non esiste :asd: :asd: )
L'unica cosa che ho trovato e' questo articolo http://www.ddj.com/cpp/184401345
che ovviamnete non ho letto :D
anche a me piace...però se si decide (ergo fek ci da la sua benedizione:D) di andare verso questa strada...non bisogna forzarla...se no si rischia di introdurre un mostro come le action:|
P.S: per me sono più le volte che dobbiamo chiedere qualcosa solo a qualcuna...però è una valutazione "ad occhio" la mia:D
Certo mi rendo conto che sarebbe un lavorone inserirlo adesso, ma secondo me sarebbe bello.
http://repos.gcoders.net/HelloWorld.patterns.example.php
anche a me piace...però se si decide (ergo fek ci da la sua benedizione:D) di andare verso questa strada...non bisogna forzarla...se no si rischia di introdurre un mostro come le action:|
P.S: per me sono più le volte che dobbiamo chiedere qualcosa solo a qualcuna...però è una valutazione "ad occhio" la mia:D
Ora l'unica cosa che dobbiamo fare e' togliere di mezzo ogni singolo Refactor This.
Qui siamo tornati a tante parole e tanti Design Pattern sul forum, ma pochi commit, e la cosa non mi piace affatto.
Togliamo tutti i Refactor This e non abbiamo davvero bisogno di altro, perche' la code base sara' usabilissima.
http://repos.gcoders.net/HelloWorld.patterns.example.php
Ok :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.