Introduzione Observer Pattern

[cisc]

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 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?

[fek]

Io sono un sostenitore del codice semplice

[cisc]

Originariamente inviato da fek

Io sono un sostenitore del codice semplice

beh...secondo me mo lo semplifica il codice

[Ufo13]

Magari fai un esempio di use case dove il codice diventerebbe piu` semplice :P

[fek]

Originariamente inviato da cisc

beh...secondo me mo lo semplifica il codice

cisc, un intero Observer Pattern per togliere un metodo (isTransforming) mi sembra giusto un briciolo over engineering

[cisc]

Originariamente inviato da Ufo13

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

Originariamente inviato da fek

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

[cionci]

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.

[Ufo13]

dp channel? :S

[cionci]

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.

[Bonfo]

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 )

L'unica cosa che ho trovato e' questo articolo http://www.ddj.com/cpp/184401345
che ovviamnete non ho letto

[cisc]

Originariamente inviato da Bonfo

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 )

L'unica cosa che ho trovato e' questo articolo http://www.ddj.com/cpp/184401345
che ovviamnete non ho letto

anche a me piace...però se si decide (ergo fek ci da la sua benedizione) 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

[fek]

Originariamente inviato da cionci

Certo mi rendo conto che sarebbe un lavorone inserirlo adesso, ma secondo me sarebbe bello.

http://repos.gcoders.net/HelloWorld....ns.example.php

[fek]

Originariamente inviato da cisc

anche a me piace...però se si decide (ergo fek ci da la sua benedizione) 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

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.

[cionci]

Originariamente inviato da fek

http://repos.gcoders.net/HelloWorld....ns.example.php

Ok