[CICLO 6/bis] Xmas Carol Story 2

[fek]

Originariamente inviato da cionci

Gli errori di stile li ho già corretti io ieri sera... Non capisco come mai la build sia ancora rotta... Sembra che non trovi una immagine...back000 che comunque è nel repository...

Riguardo alla modifica che avevi dichiarato alle 21...è chiaro che tu abbia proseguito... E' per evitare questi problemi che chiedevo a fek una wiki per tenere conto di queste cose

Ho messo su un paio di wiki sul server, ma sono entrambi piuttosto scomodi da usare. Appena torno in UK e mi trasferisco nella casa nuova, rimetto mano al server e troviamo una soluzione a questo problema.

Riguardo al commit: dopo aver letto tutti i commenti di cionci, piuttosto che aggiustare il codice perferisco si faccia un bel revert e si riparta daccapo. Si fa molto prima e si evitano problemi.

E poi, visto che questo task sta gia' creando molti problemi, fatelo in Pair Programming per favore.

[fek]

Originariamente inviato da thebol

errore mio, ma dato il la pesantezza delle modificche ho preferito lasciare qualcosa(e alle 2 di notte mi sono dimenticato di dare una controllata

Ho imparato personalmente nel modo peggiore che non si fa per nessun motivo un commit alle 2 di notte

ho dichiarato la scelta alle 21, nessuno ha detto nulla e ho proseguito.
Certo forse potevo motivare un po meglio, ma ho spiegato il perche di questa scelta(venuta in qualche modo naturale col refactoring chiesto da fek)

Colpa mia che non avevo chiarito questo punto a sufficienza: InputReactor non deve conoscere per alcun motivo le classi che fanno parte del gioco. Si sta configurando un'architettura dove InputReactor e' un servizio fornito dall'Engine agli strati superiori (il Gioco) e come tale c'e' comunicazione sempre e solo a salire, ma non a scendere.

[Ufo13]

allora reverta che ripartiamo in pair

[fek]

Originariamente inviato da Ufo13

allora reverta che ripartiamo in pair

Io non posso, a mala pena sono collegato a internet qui, sono in Italia

[thebol]

dei file che avevo cambiato ho tirato su la versione precedente, se volete committo il revert(o ce un altra maniera per farlo?).

[cionci]

Sicuramente c'è un altro modo, ma non ho mai capito come si fa...
Provo un po'...

Ufo13 e thebol: allora lo fate voi in pair programming questo task ?

[cionci]

Fatto il revert...però nel metodo rozzo

[thebol]

posso mercoledi sera, se avete fretta passo volentieri la mano

[Ufo13]

Cionci se ti offri te bene, altrimenti se vi va bene facciamo con thebol mercoledì oppure intanto faccio di refactoring per GemsPair poi si vede

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Xmas.2.3 potrei prenderlo io. Tempo previsto: 2 giornid a quando finisce Xmas.2.1.

http://www.hwupgrade.it/forum/showpo...2&postcount=16
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.....

[cionci]

Originariamente inviato da Ufo13

Cionci se ti offri te bene, altrimenti se vi va bene facciamo con thebol mercoledì oppure intanto faccio di refactoring per GemsPair poi si vede

Fallo con thebol... Io ho problemi di connessione...
GemsPair imho conviene farlo insieme al Pair Programming al momento in cui ne sentirete l'esigenza...
Tanto per farvi capire guardate fek nel pair programming con me quando ha inserito la classe Frame... In pratica complicando leggermente un test precedente sarebbero state necessarie troppe modifiche per soddisfarlo...a questo punto ha introdotto la classe Frame fatto il refactoring del codice esistente e di fatto è bastata una sola nuova istruzione per far passare il test in questione...

[Ufo13]

Seguirò il tuo consiglio

thebol se vuoi iniziare già a pubblicare il primo test io domani vedo cosa riesco a fare dall'univ

[Ufo13]

A questo punto ritengo giusto che la situazione si presentasse in questo modo:

- Grid: gestisce (inserimento / rimozione) gemme e fornisce informazioni sullo stato della griglia (solo lo strettamente necessario).

- GridController: gestisce spostamento gemme (moveLeft, moveRight), possiede informazioni sulle gemme sotto il controllo dell'utente.

Ovviamente gli EventHandler agiranno su GridController e non + su Grid direttamente...

[cionci]

In pratica così però sposteremmo tutto Grid in GridController...
Io continuerei a far gestire a Grid tutto quello che fa ora...anche perchè di fatto si andrà sempre ad agire sulla griglia...

L'unica modifica che andrebbe fatta in Grid credo che sia di portare questo codice:

       if(gemCantMoveDown(getGemUnderControl()))
        {
            alignGemToCellUpperBound(getGemUnderControl());
            getGemUnderControl().dropGem();

            if(gemIsSurroundedBySameType(getGemUnderControl()))
            {
                getGemUnderControl().useBrighterImage();
            }
        }
        else
        {
            moveGem(getGemUnderControl());
        }

in un altro metodo sempre di Grid (ad esempio potrebbe essere chiamato updateGemUnderGravity(Gem gem))...in modo da permettere l'update di tutta la coppia di gemme...
Per il resto basterà comunque passare GridCotnroller agli handlers che tramite un metodo (potrebbe essere getGemsPairUnderControl) potranno risalire alla coppia di gemme e potranno applicare il movimento direttamente alla coppia di gemme... Ovviamente GemsPair avrà un membro Grid che gli permetterà di applicare i movimenti ad entrambe le gemme...

[fek]

Originariamente inviato da cionci

in un altro metodo sempre di Grid (ad esempio potrebbe essere chiamato updateGemUnderGravity(Gem gem))...in modo da permettere l'update di tutta la coppia di gemme...
Per il resto basterà comunque passare GridCotnroller agli handlers che tramite un metodo (potrebbe essere getGemsPairUnderControl) potranno risalire alla coppia di gemme e potranno applicare il movimento direttamente alla coppia di gemme... Ovviamente GemsPair avrà un membro Grid che gli permetterà di applicare i movimenti ad entrambe le gemme...

Questa mi sembra una buona line guida per scrivere il task.

[Ufo13]

A questo punto allora gemUnderControl non ha piu` senso dentro Grid...

In pratica così però sposteremmo tutto Grid in GridController...
Io continuerei a far gestire a Grid tutto quello che fa ora...anche perchè di fatto si andrà sempre ad agire sulla griglia...

Secondo me non e` propriamente vero... Forse non mi sono spiegato bene, collisioni con gemme, fondo e bordi verrebbero ancora gestite da Grid... Sarebbero i Controlli sulle gemme (movimenti) a passare dentro GridController...

Comunque ora cerco la soluzione + semplice per la risoluzione del task (probabilmente la soluzione del metodo che proponi potrebbe aiutare)...

[cionci]

Originariamente inviato da Ufo13

A questo punto allora gemUnderControl non ha piu` senso dentro Grid...

Certamente no...

Originariamente inviato da Ufo13

Secondo me non e` propriamente vero... Forse non mi sono spiegato bene, collisioni con gemme, fondo e bordi verrebbero ancora gestite da Grid... Sarebbero i Controlli sulle gemme (movimenti) a passare dentro GridController...

Ma i movimenti vanno ad agire anche sulla griglia...

[Ufo13]

Non ho il codice sotto mano pero` cerco di spiegarmi...

Come ti ho detto Grid gestirebbe inserimento e cancellazione di gemme.

Gli spostamenti sono tranquillamente gestibili da GridController con una semplice rimozione, cambio di coordinate, reinserimento (come gia` fa Grid).

Comunque so che viene prima il task e credo di poter gestire la situazione con pochissimi refactoring

[cionci]

Ma grid deve gestirebbe ancora lo spostamento della gemme (update) quindi o si toglie tutto (e quindi anche la gestione della gravità) o si lascia tutto In pratica non rimarrebbe più niente dentro a Grid... Solo la gestioend elel collisioni...

[Ufo13]

Ho una vagonata di test che diventano incompatibili con gemsPair... Riscrivo i test per adattarli a gemsPair (prima di implementare la relativa parte testata ovviamente) o cerco di tenere quelli attuali e trovo un modo per farli funzionare?