Refactoring delle gemme e controllo ad eventi degli effetti della caduta

[cionci]

Principalmente questo refactoring si dovrà occupare di:

- creare una gerarchia di classi che includerà tutte quelle che possiamo definire Droppable (Stone, Gem, Flashing Gem, Chest, BigGem).

Secondo me a questo punto ci dovremmo fermare e verificare che tutto funzioni e tutti i test passino...

Il refactoring da effettuare successivamente sarà:

- creare un'interfaccia DroppableController, da cui deriveranno tutti i Controller delle rispettive classi della gerarchia sopra

- implementare un meccanismo in ogni classe della gerararchia che allochi e restituisca il controller che si dovrà occupare di gestire gli eventi da applicare ai Droppable

- implementare gli eventi ed un gestore di eventi (che potrebbe essere il controller)
Ad esempio questa dovrebbe essere la gestione dell'evento "una gemme si è fermata" :

DropapbleController controller = droppable.getController();
controller.onHalt(grid);

- la gestione dell'evento "tutte le gemme sono ferme" provocherà i crush, che lavoreranno in maniera diversificata a seconda del Droppable

Questa è la mia proposta...a voi

[Bonfo]

Faccio 2 puntualizzazioni per vedere se ho capito

1) Ci vuole ovviamente l'interfaccia Droppabel
2) La gestione degli eventi comporta anche la creazione di 2 interfaccie:
-quella di chi genera gli eventi
-quella di chi li ascolta, il listener

[cionci]

Originariamente inviato da Bonfo

1) Ci vuole ovviamente l'interfaccia Droppabel

Sì, ora fek preferirebbe un'interfaccia, sinceramente io preferirei una classe base

Originariamente inviato da Bonfo

2) La gestione degli eventi comporta anche la creazione di 2 interfaccie:
-quella di chi genera gli eventi
-quella di chi li ascolta, il listener

Dipende un po' da come organizzaimo la cosa...
Se esisterà una sola classe evento e ci sarà un tipo a discriminare l'evento generato, basta uno switch (soluzione che scala male)...

Se invece facciamo una classe evento per ogni evento da gestire allora bisogna definire un'interfaccia per il listener, mentre per chi genera gli eventi non ci sarà bisogno di interfaccia...

Vediamo un po' come gestirla...

I generatori di eventi potrebbero essere due: Grid e GridController... Questi sono sicuri...

Il listener dovrebbe essere GridController... Ditemi voi come pensereste di organizzare la cosa...

PS: ho pensato che, dopo, ad eventi sarebbe possibile gestire qualsiasi cosa che fa GridController...come la gestione dei vari timestamp...l'inserimento di una nuova gemma... Ditemi voi...

[Bonfo]

Originariamente inviato da cionci

Sì, ora fek preferirebbe un'interfaccia, sinceramente io preferirei una classe base

Perchè non tutte e due...interfaccia e classse astratta che implementa tale interfaccia

Originariamente inviato da cionci

Il listener dovrebbe essere GridController...

Nella mia testa era il contrario
GridControler genera l'evento e il CrushGemListener si registra all'evento

[cionci]

mmmhhh...quindi te faresti un listener per ogni evento ? Non ci avevo pensato sinceramente...

Io invece farei così, supponendo di definire una classe per ogni evento:

class DroppableHaltedEvent
{
   public processEvent(Listener listener)
   {
       listener.onDroppableHalted();
   }
}

[Bonfo]

Quindi tu faresti generare a GridController degli eventi che poi GrdiContyroller deve gestire....

Mi sembra un po' masochistico

A parte gli scherzi, penso che l'idea principale che deve guidare il refactoring di GridController è prorio quella di dividere le responsabilità.
Quello che secondo me dobbiamno fare è eliminare quell'update in GridController e trasformarlo in una semplice generazione di eventi.

Ora per amore di Ingegneria del Software dovrebbe essere possibile che all'evento "gemsPair ferma" possano corrispondere più azioni, ovvero più listener.

Quindi in conclusione io farei:
- N listener in base alle responsabilità, ovvero a che cosa deve fare. Io vedo bene come listener i GemAction...alla fine sono quelli i compiti da svolgere.
- M eventi che notificano i momenti chiave del gioco

in realtà ciò che penso io è un pattern observer, dove gli observable sono "eventi", ovvero accadimenti del gioco

------------------------------------------------------------------
GridController.registerEventGemsPairStop(CrushGemListener);

------------------------------------------------------------------
if(!gemsPairsCanMoveDown)
     for(registeredListener)
        notifyEvent()
------------------------------------------------------------------
public void notifyEvent()
{
      processEvent()
}

Così a GridController la facciamo dimagrire in fretta

[fek]

La proposta mi sembra buona, preferisco ovviamente l'interfaccia e poi, eventualmente, una classe astratta base (proprio se necesaria). L'importante e' suddividere il refactoring in piccoli passi verificabili e ben testabili. Non voglio un lungo refactoring che ha bisogno di essere concluso prima che il tutto torni a funzionare. E poi, voglio che le cose si semplifichino: non fatevi prendere la mano dal refactoring aggiungendo piu' flessibilita' di quella strettamente necessaria. Cose tipo per l'Amore dell'Ingegneria del Software mi suonano gia' male: diciamo per l'amore di semplicita' e fate le cose semplici

[Bonfo]

Originariamente inviato da fek

Cose tipo per l'Amore dell'Ingegneria del Software mi suonano gia' male: diciamo per l'amore di semplicita' e fate le cose semplici

Comunque era ironico

[cionci]

Ripeto...io non farei un listener per ogni azione da svolgere...
Io invece a questo punto farei un solo listener che contenga i vari metodi da richiamare...

class DroppableHaltedEvent implements GridEvent
{
   Droppable droppable;

   public DroppableHaltendEvent(Droppable droppable)
   {
       this.droppable = droppable;
   }

   public processEvent(GridEventHandler handler)
   {
       handler.onDroppableHalted(droppable);
   }
}


class GridEventHandler
{
   ....
   public notifyEvent(GridEvent event)
   {
      event.processEvent(this);
   }

   public onDroppableHalted(Droppable droppable)
   {
      DropapbleController controller = droppable.getController();
      controller.onHalt(grid); 
   }
}

[Ufo13]

Cionci a me la tua soluzione piace molto

[fek]

Piace anche a me. A occhio non c'e' un'indirezione di troppo? (non ci giuro affatto, probabilmente ho perso qualcosa io).

[cionci]

Però c'è una cosa che non mi sconfiffera...questo affare resta sicrono

Il mio dubbio è questo:

if(!gemsPairsCanMoveDown)
     for(registeredListener)
        notifyEvent(new DroppableHaltedEvent (droppable))

In pratica appena avviene un evento viene eseguito l'handler...allora tanto vale chiamare questo, no ????

if(!gemsPairsCanMoveDown)
     for(registeredListener)
        handler.onDroppableHalted(droppable);

Potremmo desincronizzarlo ????? Avrebbe senso ??? Sarebbe utile Semplificherebbe ?

Intendo praticamente mettere in coda gli eventi...

Dentro update di GridController avverrà l'update di Grid (che metterà in coda alcuni eventi)...verrà eseguito il resto del codice di Gridcontroller (che metterà in coda altri eventi)....a questo punto potrebbe essere chiamata gridEventHandler.processEventList() che non farà alltro che eseguire glie venti dal più vecchio al più recente...

Che ne dite ?

[cionci]

Originariamente inviato da fek

Piace anche a me. A occhio non c'e' un'indirezione di troppo? (non ci giuro affatto, probabilmente ho perso qualcosa io).

Vedi sopra...

[fek]

Originariamente inviato da cionci

Che ne dite ?

La seconda versione tutta la vita, perche' toglie un'indirezione. Al momento non vedo motivo per desincronizzare, ci interessa solo portare fuori da Grid il codice di gestione dell'evento.

[Bonfo]

Originariamente inviato da cionci

Che ne dite ?

Scusate...ma notifyEvent() è senza parametro.
Io la metteri perchè all'interno di questo metodo, anche privato, vengono invocati tutti i handler.onDroppableHalted(droppable);....

....però se si usa un solo handler, ovvero listener, va bene uguale

[cionci]

Originariamente inviato da Bonfo

vengono invocati tutti i handler.onDroppableHalted(droppable);....

No, ne viene invocato solo uno...

[cionci]

Ma quando ci lavoriamo su questo refactoring ?

[Ufo13]

Propongo un'altra cosa:

all'interno di GridController quando una GemsPair viene droppata viene eseguito qualcosa, viene atteso un tot di tempo, di nuovo viene eseguito qualcosa etc...

Non sarebbe bello un observer pattern con tot observers?

[Bonfo]

é quello che volevo fare con i listener, ovveo gli observer

[thebol]

io butto li un idea...

introdurre una specie di pattern state in gridController(uno per quando ci sono le gemme in movimento, uno per quando si fa cadere le gemme che possono cadere, uno per le crush, uno per l'update delle stone, etc), che contengano un metodo update(che faccia il lavoro per quello stato), e che restituiscano lo stato successivo del gridController. In modo da simulare una specie di macchina a stati.