REFACTORING: Responsabilità di ACTION e STATE

[Bonfo]

Riprendo su consiglio di fek da questo thread
http://www.hwupgrade.it/forum/showthread.php?t=1200994

Il problema è il seguente....quali sono le caratteriastiche di Action e State e quale è la relazione tra di loro e con Grid e GridController??

Come orientare il refactoring? Cosa diventa state e cosa Action??

Ecco la prima idea proposta da fek:

La definizione di Action e' "il solo componente che puo' cambiare la configurazione e lo stato di un GridController". La definizione di State e' "Lo stato corrente di GridController che restituisce la prossima Action da eseguire"

Prime cosa che direi: bisogna aggiungere una StoneInsertAction, utilizzata poi da StoneFallState.
Che ne dite poi di una GravityAction??

[fek]

Inizi con queste due Action e i relativi test, e poi vediamo come proseguire.

[thebol]

Originariamente inviato da Bonfo

Riprendo su consiglio di fek da questo thread
http://www.hwupgrade.it/forum/showthread.php?t=1200994

Il problema è il seguente....quali sono le caratteriastiche di Action e State e quale è la relazione tra di loro e con Grid e GridController??

Come orientare il refactoring? Cosa diventa state e cosa Action??

Ecco la prima idea proposta da fek:


Prime cosa che direi: bisogna aggiungere una StoneInsertAction, utilizzata poi da StoneFallState.
Che ne dite poi di una GravityAction??

non avevo pensato a fare di ogni modifica di grid un action. Penso sia fattibile.
Cmq cè da aggiungere anche una action per le gemsPair.

[thebol]

solo una cosa:
il fatto che uno state restituisca una action ci sta.

il fatto che una action restituisca uno state un po meno.

Per me sarebbe meglio che sia lo state a chiamare la action, e a restituire uno state.

Lo state contiene la condizione per eseguire uno state, e per passare al prox state(che puo sempre essere se stesso).

Cosi nelle action non cè nessuna logica di stato, ma solo di azione.

[fek]

Originariamente inviato da thebol

solo una cosa:
il fatto che uno state restituisca una action ci sta.

il fatto che una action restituisca uno state un po meno.

Per me sarebbe meglio che sia lo state a chiamare la action, e a restituire uno state.

Lo state contiene la condizione per eseguire uno state, e per passare al prox state(che puo sempre essere se stesso).

Cosi nelle action non cè nessuna logica di stato, ma solo di azione.

Buona idea.