Problema architetturale

[thebol]

il titolo è pomposo ma la domanda è sempliciotta

ho separato gemFactory, introducendo RandomGemFactory che implementa solo i metodi getRandomQualcosa, mentre l'altra è solo per ottenere le gemme, chest, etc.

Naturalmente RandomGemFactory usa gemFactory, che nell'implementazione attuale viene usata anche in updateStoneAction. Per cui ho "alzato" il momento di creazione del GemFactory in modo da usare un unico oggetto(non ha stato) in entrambi i posti. Ma mi è venuta l'idea di spostare la creazione ancora piu in alto, in modo che entrambi i playField (e tutto quello che contengono) abbiano il riferimento allo stesso oggetto.

Ora mi chiedo, è una cosa inutile e brutta, o avrebbe un senso farlo?


Altra cosa, posso committare indipendentemente dall'altro refactoring?(una factory per gem penso sia utile)

[Bonfo]

Forse si porebbe un problema.
Noi utilizziamo due generator inizializzati con lo stesso seed uno per palyField....se utilizziamo un oggetto solo alla fine non potremmo più avere la stessa sequenza di gemme tra i due field

[thebol]

Originariamente inviato da Bonfo

Forse si porebbe un problema.
Noi utilizziamo due generator inizializzati con lo stesso seed uno per palyField....se utilizziamo un oggetto solo alla fine non potremmo più avere la stessa sequenza di gemme tra i due field

il seed sarebbe usato nel randomFactoryGem, che continuerebbe a rimanere separato per i 2 field, mentre in comune rimarebbe solo il gemFactory che crea semplicemente delle gemme.

[Ufo13]

secondo me intanto potresti commitare

[Bonfo]

Originariamente inviato da thebol

il seed sarebbe usato nel randomFactoryGem, che continuerebbe a rimanere separato per i 2 field, mentre in comune rimarebbe solo il gemFactory che crea semplicemente delle gemme.

Ok...mi ero perso un passaggio.
Per me ha senso...

[fek]

Originariamente inviato da thebol

il titolo è pomposo ma la domanda è sempliciotta

ho separato gemFactory, introducendo RandomGemFactory che implementa solo i metodi getRandomQualcosa, mentre l'altra è solo per ottenere le gemme, chest, etc.

Naturalmente RandomGemFactory usa gemFactory, che nell'implementazione attuale viene usata anche in updateStoneAction. Per cui ho "alzato" il momento di creazione del GemFactory in modo da usare un unico oggetto(non ha stato) in entrambi i posti. Ma mi è venuta l'idea di spostare la creazione ancora piu in alto, in modo che entrambi i playField (e tutto quello che contengono) abbiano il riferimento allo stesso oggetto.

Ora mi chiedo, è una cosa inutile e brutta, o avrebbe un senso farlo?

A me l'idea non piace molto. Non sono un grande fan del memorizzare riferimenti indietro ad oggetti creatori o manager: per esperienza mi hanno creato sempre piu' problemi di quelli che hanno risolto. Inoltre viola il principio secondo il quale ogni operazione dovrebbe ricevere la minima quantita' di informazioni necessaria per poter essere eseguita. Memorizzare un riferimento allo stesso oggetto significa fornire tutte le informazioni di quello oggetto per tutto il life time: nel 99% dei casi e' fin troppo.

[thebol]

Originariamente inviato da fek

A me l'idea non piace molto. Non sono un grande fan del memorizzare riferimenti indietro ad oggetti creatori o manager: per esperienza mi hanno creato sempre piu' problemi di quelli che hanno risolto. Inoltre viola il principio secondo il quale ogni operazione dovrebbe ricevere la minima quantita' di informazioni necessaria per poter essere eseguita. Memorizzare un riferimento allo stesso oggetto significa fornire tutte le informazioni di quello oggetto per tutto il life time: nel 99% dei casi e' fin troppo.

ok, non ho ancora commitato che ho avuto problemi con eclipse e il portatile.

seguendo questa filosofia, posso far creare il gemFactory a chi serve(per farlo basta il config che nel costruttore lo hanno quasi tutti gli oggetti).

[fek]

Originariamente inviato da thebol

ok, non ho ancora commitato che ho avuto problemi con eclipse e il portatile.

seguendo questa filosofia, posso far creare il gemFactory a chi serve(per farlo basta il config che nel costruttore lo hanno quasi tutti gli oggetti).

Assolutamente si', buona idea

[thebol]

non sono ancora riuscito a fare il commit della divisione delle droppable factory, visto che becco sempre spartacus giu.

pero oggi sono riuscito a introddurre il pattern state in gridController, il problema e che l'ho fatto su una versione vecchia di 2 giorni(per i problemi di cui sopra), percui quando riesco a fare sync la rifaccio da capo.

Ho introdotto un interfaccio gridControllerState con un metodo update, che ritorna un tipo gridControllerState. In questo modo la succesione degli stati è affidata agli stati stessi. Per ora ho solo suddiviso in stati(pre insert gempair, postInsertGemPair e gameOverState), ma prevedo di inserire anche lo stato per le crush.

Magicamente ( )l'introduzione di questo pattern non tocca assolutamente i test che hanno continuato(risolto un buggettino..) a essere verdi \o/

[fek]

Molto bene, quel codice urlava per uno State pattern

[Ufo13]

hmmm ma hai commitato?

[thebol]

Originariamente inviato da Ufo13

hmmm ma hai commitato?

stamattina lo sdoppio di DroppableFactory.

per lo state vedo se riesco a fare qualcosa entro stasera, se no mi ci metto domani(o solo la mattina prima del lavoro e la sera per committare...)

[Ufo13]

Originariamente inviato da thebol

stamattina lo sdoppio di DroppableFactory.

per lo state vedo se riesco a fare qualcosa entro stasera, se no mi ci metto domani(o solo la mattina prima del lavoro e la sera per committare...)

Non è che riesci a committare in mattinata per favore? Sarebbe molto meglio in quanto quella parte quasi sicuramente verrà modificata

[thebol]

alcune classi hanno viaggiato parecchio, ho appena creato 2 package per gli state e per le action e le ho raggruppate li dentro(in grid si faceva casino..)

[Ufo13]

Ci avevo pensato anche io ma Fek mi ha fermato.. Puoi rimetterle come prima?

Per favore potresti mica testare gli state che hai implementato?

[thebol]

Originariamente inviato da Ufo13

Ci avevo pensato anche io ma Fek mi ha fermato.. Puoi rimetterle come prima?

Per favore potresti mica testare gli state che hai implementato?

ok, ma non sono molto d'accordo...

gli state e le action in un unico package sono molto incasinate...


per i test, ho in programma di farli, voglio spezzare ulteriormente il crushState in 2 e poi incomincio.

[Ufo13]

Originariamente inviato da thebol

ok, ma non sono molto d'accordo...

gli state e le action in un unico package sono molto incasinate...


per i test, ho in programma di farli, voglio spezzare ulteriormente il crushState in 2 e poi incomincio.

Hmmm io darei la precedenza ai test :P

[thebol]

ho un problema...
sto ulteriormente suddividendo crushState, e ho notato un comportamento non necessario.
Quando viene chiamato crushState, prima di fare la prima crush, controlla droppedGemCanMoveDown(). Questo fa funzionare molti test, ma non è una necessaria.

Mi spiego...

in game, la crushState viene chiamata dopo che la gemsPair e arrivata sul fondo, percui questo controllo non è necessario(altri controlli fra le varie crush finiranno in un altro stato).

pero nei test questo comportamento è utile, visto che di solito si inseriscono le gemme, si inserisce e si stoppa una gemsPair, la si fa cadere e poi incominciano le crush. Questo è un comportamento non necessario, ma utile.

Penso per adesso di riuscire a replicare il comportamento precedente, ma sarebbe da valutare se mantenerlo anche in futuro(ci sarebbero da cambiare parecchi test...)

[fek]

Originariamente inviato da thebol

Penso per adesso di riuscire a replicare il comportamento precedente, ma sarebbe da valutare se mantenerlo anche in futuro(ci sarebbero da cambiare parecchi test...)

Se il cambiamento porta ad una semplificazione del codice e mantiene la stessa copertura, direi che e' il caso di farlo. La valutazione e' tua.

Ma dopo la First Playable. Fino al 21 siamo concentrati sulla check list e dobbiamo posticipare i grossi refactoring e accumulare qualche debito.

[thebol]

Originariamente inviato da fek

Se il cambiamento porta ad una semplificazione del codice e mantiene la stessa copertura, direi che e' il caso di farlo. La valutazione e' tua.

Ma dopo la First Playable. Fino al 21 siamo concentrati sulla check list e dobbiamo posticipare i grossi refactoring e accumulare qualche debito.

ok, fra l'altro alla fine la cosa mi è venuta comoda...
il grosso problema e che il comportamento alla prima crush è diverso dalle successive.
btw sono solo a 3 test falliti, ci sono quasi