proposta di refactoring per smaltire un po' Grid

[71104]

mi sono letto tutto il codice di Grid: l'ho trovato fatto abbastanza bene (molto semplice), ma come tutti sappiamo è una classe troppo grossa; leggendo il codice sono giunto alla conclusione che Grid si occupa essenzialmente di due compiti:
1) gestione della griglia (banalmente la matrice di gemme, sulla quale però sono definite molte operazioni anche complesse a causa per esempio delle big gems)
2) sistema di gravità

e adesso naturalmente sta per aggiungersi un nuovo compito minore, ovvero il controllo sul numero di candelotti di dinamite (massimo 3 mi sembra); e forse sarebbe bene spostarlo in una classe più "alta" come GridController

per dividere la classe Grid, che ne pensate se mettiamo il codice per la gestione della gravità in una nuova classe GravitySystem? secondo voi potrebbe semplificare Grid significativamente? mi sembrerebbe una buona idea perché a quel punto a Grid rimarrebbe l'unico compito della gestione della matrice, e come design sarebbe assolutamente perfetto.

[cisc]

a mio avviso dopo il refactoring relativo al rendere le bigGem Droppable, seguendo il concetto proposto da Bonfo secondo il quale devono essere le droppable a sapere se possono muoversi e dove, grid si semplificherà notevolmente...secondo me il tuo refactoring è ancora YAGNI, potrebbe essere utile in seguito, ma adesso andrebbe a banalizzare il ruolo di grid....

[Ufo13]

Originariamente inviato da cisc

a mio avviso dopo il refactoring relativo al rendere le bigGem Droppable, seguendo il concetto proposto da Bonfo secondo il quale devono essere le droppable a sapere se possono muoversi e dove, grid si semplificherà notevolmente...secondo me il tuo refactoring è ancora YAGNI, potrebbe essere utile in seguito, ma adesso andrebbe a banalizzare il ruolo di grid....

Non sono molto d'accordo... Secondo me non è troppo YAGNI direi

[71104]

allora aspettiamo di vedere cosa succede a Grid dopo il refactoring e vediamo se è ancora il caso di attuare questa mia mezza idea.

[Bonfo]

Originariamente inviato da 71104

allora aspettiamo di vedere cosa succede a Grid dopo il refactoring e vediamo se è ancora il caso di attuare questa mia mezza idea.

Anche secondo me non è così YANGI....comunque, se andate nel post Action e State, era stata proposto addirttura un Action adibita a questo compito.

Inoltre ripeto in questa sede che una delle cose che semplificherebbe al massimo Grid sarebbe trasformala da una classe che gestisce un'insieme di Celle ad un'iniseme di Droppable.
Sparirebbe la lista di BigGems che deve essere mantenuta per ricordarsi quale BigGem sono già state visitate, evitando così i numerosi clicli di controllo per gestire questa cosa

[cisc]

secondo me, rendendo le bigGem droppable, e seguendo il concetto per cui le bigGem non sono un agglomerato di gemme, ma delle gemme più grandi (come anche il nome suggerisce), è inevitabile trasformare grid in modo che gestisca un insieme di Droppable e non un insieme di celle......

[Bonfo]

Originariamente inviato da cisc

secondo me, rendendo le bigGem droppable, e seguendo il concetto per cui le bigGem non sono un agglomerato di gemme, ma delle gemme più grandi (come anche il nome suggerisce), è inevitabile trasformare grid in modo che gestisca un insieme di Droppable e non un insieme di celle......

Che bello

[thebol]

Originariamente inviato da cisc

secondo me, rendendo le bigGem droppable, e seguendo il concetto per cui le bigGem non sono un agglomerato di gemme, ma delle gemme più grandi (come anche il nome suggerisce), è inevitabile trasformare grid in modo che gestisca un insieme di Droppable e non un insieme di celle......

sarei favorevole, ma cè da tenere conto che la gravità va applicata riga per riga, altrimenti non funziona

[Bonfo]

Originariamente inviato da thebol

sarei favorevole, ma cè da tenere conto che la gravità va applicata riga per riga, altrimenti non funziona

allora a che cosa serve il metodo applayGravity che c'è in AbstractDroppable??

Forse ho capito male io

[fek]

Originariamente inviato da 71104

per dividere la classe Grid, che ne pensate se mettiamo il codice per la gestione della gravità in una nuova classe GravitySystem? secondo voi potrebbe semplificare Grid significativamente? mi sembrerebbe una buona idea perché a quel punto a Grid rimarrebbe l'unico compito della gestione della matrice, e come design sarebbe assolutamente perfetto.

Si', e' una buona idea, sono letteralmente mesi che ci penso e non l'ho mai fatto. Appena abbiamo finito con le BigGems e' un passo decisamente fattibile.

[thebol]

Originariamente inviato da Bonfo

allora a che cosa serve il metodo applayGravity che c'è in AbstractDroppable??

Forse ho capito male io

ricordavo che una volta era cosi...
il giro nuovo non lo conosco molto bene, magari ora funziona in ogni caso

[thebol]

stavo valutando il refactoring di action e state, e mi sarebbe molto comodo avere una action per la gravità(quindi loggabile), da chiamare negli state.

Non so se convergerebbe in un GravitySistem, ma cmq provo a vedere cosa ne viene fuori.