[CICLO 6/bis] Xmas Carol Story 2

[cionci]

Io lascerei la possibilità a Grid e GridController di gestire anche una gemma da sola... In tal caso tutti i test continuano a valere... Comunque credo che se bisogna lasciare questa possibilità te lo dovrebbero dire VICIUS e Jocchan...

[thebol]

avendo gia fatto questo refactoring, do qualche mia impressione su quello che ho fatto e che andra fatto:

-sposterei gemUnderControll da grid a gridController, spostando solo la gestione dell'update e relativi get & set di gemUnderControll, questo perche nella mia idea il Gridcontroller faceva muovere le gemme sotto controllo(dicendo a grid di spostare la gemma X a sx di 1, poi e grid che fisicamente la sposta).


- i movimenti di una singola gemma(con annessi check dei bordi, gemme, etc) li lascerei in grid, che cercherei di far essere una semplice griglia dove mettere gemme, spostarle, etc


-introduzione della seconda gemma, test, e poi refactoring di gemPair. Si guarderà se gridController gestirà 2 casi (2 gemme e 1 gemma) o questo lavoro possa essere fatto da gemPair, che settata in maniera opportuna funzioni anche come gemma(forse non avrebbe molto senso logico).

-tutto il resto da fare come task.




Altra cosa carina da fare alla fine del task(o anche prima in parallelo), sarebbe astrarre una classe di test, con una setup che definisca grid, gridController, input, inputReactor, timer, etc di test. In questa maniera, refactoring di questo tipo, avrebbero un minore impatto sui test.


a stasera, ora vado a lavoro(e niente internet :| )

[cionci]

Originariamente inviato da thebol

-introduzione della seconda gemma, test, e poi refactoring di gemPair. Si guarderà se gridController gestirà 2 casi (2 gemme e 1 gemma) o questo lavoro possa essere fatto da gemPair, che settata in maniera opportuna funzioni anche come gemma(forse non avrebbe molto senso logico).

In teoria GemsPair dovrebbe continuare a lavorare anche quando c'è una sola gemma al suo interno... Vedi il caso di separazione delle gemme, ma non so se sia ancora arrivato il momento per gestire la separazione delle gemme (anzi, non credo, se una delle due gemme si arresta deve arrestarsi anche l'altra)... In ogni caso credo che semplicemente dovete controllare che, se c'è una sola gemma sotto controllo (e attualmente sarà solo la gemma Pivot), gemsPair continui a funzionare...

[Ufo13]

Io in teoria avrei già quasi finito il task

Però forse meglio farlo in pair... Comunque quando riapre il SVN committo un paio di refactoring utili

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

http://www.hwupgrade.it/forum/showpo...2&postcount=16

Non me n'ero accorto. Chissà dove avevo la testa...

cmq mi sa ke te lo devo lasciare...
in questi giorni ci sono delle scadenze e arrivo a casa troppo distrutto per mettermi a programmare.....

A chi lo dici. Venerdì pomeriggio vado in ferie per una decina di giorni (a Roma), e in questo periodo sto lavorando come un matto...

[71104]

Originariamente inviato da cdimauro

A chi lo dici. Venerdì pomeriggio vado in ferie per una decina di giorni (a Roma), e in questo periodo sto lavorando come un matto...

che zona di Roma? Eur? Roma 70? Torrino? Mostacciano? Spinaceto? ...?

[Ufo13]

Intanto ho committato un paio di refactoring... domani ho due esami e non posso fare molto

[cdimauro]

Originariamente inviato da 71104

che zona di Roma? Eur? Roma 70? Torrino? Mostacciano? Spinaceto? ...?

Francamente non lo so. Ricordo soltanto che di recente nella zona hanno costruito un Ikea, e che hanno aggiunto una bretella al raccordo anulare.

Comunque se c'è da vedersi, qualunque sia la zona, non penso che ci siano problemi.

Io avrò soltanto la possibilità di leggere la posta, per cui se si organizza qualcosa dovrei essere disponibile. Contattatemi via e-mail (non PVT), nell'eventualità, che vi passo il numero del mio cellulare...

[VICIUS]

In questi giorni non sono stato molto presente e ho perso un po il file. Qual'è lo stato attuale dei task? Ne avete già completato qualcuno?

ciao

[Ufo13]

Purtroppo no... Da stasera ho tutto il tempo per lavorarci (ho dato 2 esami oggi ed i giorni scorsi non ho avuto troppo tempo e quando lo avevo nessuno si era offerto per il pair...)

[cionci]

Ufo: InputReactor non deve contenere la definizione degli handlers !!! E' una classe generica...quindi la definizione degli handlers che servono a GridController deve stare dentro a GridController...

[Ufo13]

Questo si può sistemare senza problemi

[fek]

Originariamente inviato da Ufo13

Questo si può sistemare senza problemi

Per favore, mantenete InputReactor generico. InputReactor NON deve in nessun modo dipendere da alcuna classe definita al di fuori del package di input (classi di sistema escluse ovviamente).

[Ufo13]

sì, considera anche che GridController non deve fare da Factory per un oggetto InputReactor

[Ufo13]

A me ora non va il SVN...


Comunque il metodo grid() è non testato in GridController... Non andrebbe testato?

[cionci]

Originariamente inviato da Ufo13

sì, considera anche che GridController non deve fare da Factory per un oggetto InputReactor

Per carità, quello che c'era era prima non era il massimo...ma secondo me non serve nemmeno il factory method per GridController, ma basta un nuovo costruttore...

InputReactor IMHO non deve avere un factory method per ogni classe che lo userà (visto che implica andare a modificare InputReactor per ogni classe che lo usa)...

Secondo me meglio trasferire tutto in un costruttore...

[cdimauro]

Ragazzi, tra qualche ora parto per Roma. Ci vediamo al mio ritorno. Ne approfitto per fare gli auguri di buone feste a tutti.

[Ufo13]

Originariamente inviato da cionci

Per carità, quello che c'era era prima non era il massimo...ma secondo me non serve nemmeno il factory method per GridController, ma basta un nuovo costruttore...

InputReactor IMHO non deve avere un factory method per ogni classe che lo userà (visto che implica andare a modificare InputReactor per ogni classe che lo usa)...

Secondo me meglio trasferire tutto in un costruttore...

Non so se hai ben capito quello che dicevo io o se io ho ben capito quello che stai dicendo tu

Intendi dire che non serve il Factory Method in GridController e nemmeno in InputReactor e che sarebbe meglio portare tutto dentro il costruttore di GridController?

A me non piace ricorrere a Factory se non strettamente necessario/utile (vedi createForTesting)...

[DanieleC88]

Originariamente inviato da cdimauro

Ragazzi, tra qualche ora parto per Roma. Ci vediamo al mio ritorno. Ne approfitto per fare gli auguri di buone feste a tutti.

Buon viaggio e grazie degli auguri, ricambio.

[cionci]

Originariamente inviato da Ufo13

Intendi dire che non serve il Factory Method in GridController e nemmeno in InputReactor e che sarebbe meglio portare tutto dentro il costruttore di GridController?

Sì

Aggiungendo un factory method a InputReactor non togli alcuna duplicazione, quindi imho è un refactoring non necessario... Il factory method serve proprio per eliminare le duplicazioni...

L'aggiunta degli handler necessari a Grid è compito di GridController...e quindi deve essere fatta nel costruttore...

Magari il factory method di GridController in futuro potrebbe essere necessario (anche se secondo me potrebbe benissimo andarci un costruttore al suo posto), ma quello di InputReactor in futuro non farà altro che complicare il design...visto che dovremmo aggiungere un factory method per ogni classe che usa handlers diversi (e applica handlers diversi a classi diverse)...

Comunque nell'ultima build ho spostato il contenuto del factory method di InputReactor nel costruttore di GridController...

Tra l'altro anche il fatto stesso che GridController astrae sia Grid che InputReactor giustificherebbe la loro allocazione all'interno di un costruttore...