View Full Version : Refactoring delle gemme e controllo ad eventi degli effetti della caduta
Principalmente questo refactoring si dovrà occupare di:
- creare una gerarchia di classi che includerà tutte quelle che possiamo definire Droppable (Stone, Gem, Flashing Gem, Chest, BigGem).
Secondo me a questo punto ci dovremmo fermare e verificare che tutto funzioni e tutti i test passino...
Il refactoring da effettuare successivamente sarà:
- creare un'interfaccia DroppableController, da cui deriveranno tutti i Controller delle rispettive classi della gerarchia sopra
- implementare un meccanismo in ogni classe della gerararchia che allochi e restituisca il controller che si dovrà occupare di gestire gli eventi da applicare ai Droppable
- implementare gli eventi ed un gestore di eventi (che potrebbe essere il controller)
Ad esempio questa dovrebbe essere la gestione dell'evento "una gemme si è fermata" :
DropapbleController controller = droppable.getController();
controller.onHalt(grid);
- la gestione dell'evento "tutte le gemme sono ferme" provocherà i crush, che lavoreranno in maniera diversificata a seconda del Droppable
Questa è la mia proposta...a voi :)
Faccio 2 puntualizzazioni per vedere se ho capito ;)
1) Ci vuole ovviamente l'interfaccia Droppabel
2) La gestione degli eventi comporta anche la creazione di 2 interfaccie:
-quella di chi genera gli eventi
-quella di chi li ascolta, il listener
1) Ci vuole ovviamente l'interfaccia Droppabel
Sì, ora fek preferirebbe un'interfaccia, sinceramente io preferirei una classe base
2) La gestione degli eventi comporta anche la creazione di 2 interfaccie:
-quella di chi genera gli eventi
-quella di chi li ascolta, il listener
Dipende un po' da come organizzaimo la cosa...
Se esisterà una sola classe evento e ci sarà un tipo a discriminare l'evento generato, basta uno switch (soluzione che scala male)...
Se invece facciamo una classe evento per ogni evento da gestire allora bisogna definire un'interfaccia per il listener, mentre per chi genera gli eventi non ci sarà bisogno di interfaccia...
Vediamo un po' come gestirla...
I generatori di eventi potrebbero essere due: Grid e GridController... Questi sono sicuri...
Il listener dovrebbe essere GridController... Ditemi voi come pensereste di organizzare la cosa...
PS: ho pensato che, dopo, ad eventi sarebbe possibile gestire qualsiasi cosa che fa GridController...come la gestione dei vari timestamp...l'inserimento di una nuova gemma... Ditemi voi...
Sì, ora fek preferirebbe un'interfaccia, sinceramente io preferirei una classe base
Perchè non tutte e due...interfaccia e classse astratta che implementa tale interfaccia ;)
Il listener dovrebbe essere GridController...
Nella mia testa era il contrario :eek:
GridControler genera l'evento e il CrushGemListener si registra all'evento
mmmhhh...quindi te faresti un listener per ogni evento ? Non ci avevo pensato sinceramente...
Io invece farei così, supponendo di definire una classe per ogni evento:
class DroppableHaltedEvent
{
public processEvent(Listener listener)
{
listener.onDroppableHalted();
}
}
Quindi tu faresti generare a GridController degli eventi che poi GrdiContyroller deve gestire.... :eekk: :eekk:
Mi sembra un po' masochistico :ciapet:
A parte gli scherzi, penso che l'idea principale che deve guidare il refactoring di GridController è prorio quella di dividere le responsabilità.
Quello che secondo me dobbiamno fare è eliminare quell'update in GridController e trasformarlo in una semplice generazione di eventi.
Ora per amore di Ingegneria del Software dovrebbe essere possibile che all'evento "gemsPair ferma" possano corrispondere più azioni, ovvero più listener.
Quindi in conclusione io farei:
- N listener in base alle responsabilità, ovvero a che cosa deve fare. Io vedo bene come listener i GemAction...alla fine sono quelli i compiti da svolgere.
- M eventi che notificano i momenti chiave del gioco
in realtà ciò che penso io è un pattern observer, dove gli observable sono "eventi", ovvero accadimenti del gioco
------------------------------------------------------------------
GridController.registerEventGemsPairStop(CrushGemListener);
------------------------------------------------------------------
if(!gemsPairsCanMoveDown)
for(registeredListener)
notifyEvent()
------------------------------------------------------------------
public void notifyEvent()
{
processEvent()
}
Così a GridController la facciamo dimagrire in fretta :Prrr:
La proposta mi sembra buona, preferisco ovviamente l'interfaccia e poi, eventualmente, una classe astratta base (proprio se necesaria). L'importante e' suddividere il refactoring in piccoli passi verificabili e ben testabili. Non voglio un lungo refactoring che ha bisogno di essere concluso prima che il tutto torni a funzionare. E poi, voglio che le cose si semplifichino: non fatevi prendere la mano dal refactoring aggiungendo piu' flessibilita' di quella strettamente necessaria. Cose tipo per l'Amore dell'Ingegneria del Software mi suonano gia' male: diciamo per l'amore di semplicita' e fate le cose semplici :)
Cose tipo per l'Amore dell'Ingegneria del Software mi suonano gia' male: diciamo per l'amore di semplicita' e fate le cose semplici :)
:ave: :ave: :ave:
Comunque era ironico :Prrr:
Ripeto...io non farei un listener per ogni azione da svolgere...
Io invece a questo punto farei un solo listener che contenga i vari metodi da richiamare...
class DroppableHaltedEvent implements GridEvent
{
Droppable droppable;
public DroppableHaltendEvent(Droppable droppable)
{
this.droppable = droppable;
}
public processEvent(GridEventHandler handler)
{
handler.onDroppableHalted(droppable);
}
}
class GridEventHandler
{
....
public notifyEvent(GridEvent event)
{
event.processEvent(this);
}
public onDroppableHalted(Droppable droppable)
{
DropapbleController controller = droppable.getController();
controller.onHalt(grid);
}
}
Cionci a me la tua soluzione piace molto :)
Piace anche a me. A occhio non c'e' un'indirezione di troppo? (non ci giuro affatto, probabilmente ho perso qualcosa io).
Però c'è una cosa che non mi sconfiffera...questo affare resta sicrono :muro: :muro: :muro:
Il mio dubbio è questo:
if(!gemsPairsCanMoveDown)
for(registeredListener)
notifyEvent(new DroppableHaltedEvent (droppable))
In pratica appena avviene un evento viene eseguito l'handler...allora tanto vale chiamare questo, no ????
if(!gemsPairsCanMoveDown)
for(registeredListener)
handler.onDroppableHalted(droppable);
Potremmo desincronizzarlo ????? Avrebbe senso ??? Sarebbe utile Semplificherebbe ?
Intendo praticamente mettere in coda gli eventi...
Dentro update di GridController avverrà l'update di Grid (che metterà in coda alcuni eventi)...verrà eseguito il resto del codice di Gridcontroller (che metterà in coda altri eventi)....a questo punto potrebbe essere chiamata gridEventHandler.processEventList() che non farà alltro che eseguire glie venti dal più vecchio al più recente...
Che ne dite ?
Piace anche a me. A occhio non c'e' un'indirezione di troppo? (non ci giuro affatto, probabilmente ho perso qualcosa io).
Vedi sopra...
Che ne dite ?
La seconda versione tutta la vita, perche' toglie un'indirezione. Al momento non vedo motivo per desincronizzare, ci interessa solo portare fuori da Grid il codice di gestione dell'evento.
Che ne dite ?
Scusate...ma notifyEvent() è senza parametro. :O
Io la metteri perchè all'interno di questo metodo, anche privato, vengono invocati tutti i handler.onDroppableHalted(droppable);....
....però se si usa un solo handler, ovvero listener, va bene uguale :D
vengono invocati tutti i handler.onDroppableHalted(droppable);....
No, ne viene invocato solo uno...
Ma quando ci lavoriamo su questo refactoring ?
Propongo un'altra cosa:
all'interno di GridController quando una GemsPair viene droppata viene eseguito qualcosa, viene atteso un tot di tempo, di nuovo viene eseguito qualcosa etc...
Non sarebbe bello un observer pattern con tot observers?
é quello che volevo fare con i listener, ovveo gli observer ;)
io butto li un idea...
introdurre una specie di pattern state in gridController(uno per quando ci sono le gemme in movimento, uno per quando si fa cadere le gemme che possono cadere, uno per le crush, uno per l'update delle stone, etc), che contengano un metodo update(che faccia il lavoro per quello stato), e che restituiscano lo stato successivo del gridController. In modo da simulare una specie di macchina a stati.
thebol, secondo me sarebbe ottimo, il codice ora è troppo complesso...
Propongo un'altra cosa:
all'interno di GridController quando una GemsPair viene droppata viene eseguito qualcosa, viene atteso un tot di tempo, di nuovo viene eseguito qualcosa etc...
Non sarebbe bello un observer pattern con tot observers?
Secondo me complicherebbe di più... Mi fai un esempietto ?
Ma quando ci lavoriamo su questo refactoring ?
Se puoi farlo passo passo puoi partire quando vuoi.
Mi puoi scrivere qui i passi per favore?
La prima parte (la creazione della gerarchia), senza includere le BigGem si può fare anche subito... Tanto su quella siamo tutto d'accordo, no ?
- creazione dell'interfaccia droppable
- creazione della classe base dei Droppable (come la chiamiamo ?)
- creazione delle varie classi (Gem, Chest, FlashingGem, Stone)
Stavo provando a fare la cosa sopra, ma Java non ammette metodi static nelle interfacce !!! :muro: Mi serviva per createForTesting...
Secondo me complicherebbe di più... Mi fai un esempietto ?
Ti butto proprio una bozza... In GridController:
private void registerObservers()
{
observers.add(incomingStonesObserver);
observers.add(crushesObserver);
}
private void onGemsPairStopped()
{
foreach(observer in observers)
{
observer.do(this);
wait(observer.waitTime());
}
}
Non mi torna quel wait...cosa fa ?
Intano ho fatto la gerarchia delle classi semplici... Invece per BigGem bisogna lavorarci molto...anche se volendo si potrebbe vedere BigGem come una collection di Gem (quale già adesso è), ma che comunque implementa l'interfaccia Droppable...
Tutti i test passano ed il gioco funziona alla perfezione... Ora si lavora solo su Droppable...
Bisogna mettersi a modificare un po' il GemType... Secondo me andrebbe suddiviso in due classi:
DroppableType e DroppableColor... Che ne dite ?
Intano ho fatto la gerarchia delle classi semplici... Invece per BigGem bisogna lavorarci molto...anche se volendo si potrebbe vedere BigGem come una collection di Gem (quale già adesso è), ma che comunque implementa l'interfaccia Droppable...
Tutti i test passano ed il gioco funziona alla perfezione... Ora si lavora solo su Droppable...
Bisogna mettersi a modificare un po' il GemType... Secondo me andrebbe suddiviso in due classi:
DroppableType e DroppableColor... Che ne dite ?
Sì quello avevo anche io intenzione di farlo.
Il wait sarebbe per le situazioni in cui dopo i crush bisogna aspettare N ms e poi far cadere le nuova GemsPair". Era solo per fare un esempio :)
Stavo provando a fare la cosa sopra, ma Java non ammette metodi static nelle interfacce !!! :muro: Mi serviva per createForTesting...
implementarlo nella classe Factory?
aspe che fra un po la committo...
thebol, secondo me sarebbe ottimo, il codice ora è troppo complesso...
in sti giorni ci do un occhiata
Aspe...non committate...per favore...sto facendo un refactoring bello grosso (appunto quello di Type e Color)...
Perchè mi ha dato questo errore su Chest ?!?!?
E:\Java\workspace\Diamonds\src\it\diamonds\gems\Chest.java:4: Class Chest should be declared as final.
final ce l'ho messo, ma non capisco eprchè checkstyle lo voglia :confused:
Ma con final il checkstyle ti passa??
Sì...ora ho fatto il commit, così puoi vedere...
Per me hai committao un checkstyle un po' fallato.
Guarda cosa non mi fa passare:
private static int[] DEFAULT = { 1, 2, 2, 3, 3, 4, 4, 5 };
Name 'DEFAULT' must match pattern '^[a-z][a-zA-Z0-9]*$'
Ed ecco cosa mi fa passare :
private static int[] dEFAULT = { 1, 2, 2, 3, 3, 4, 4, 5 };
:eekk: :eekk: :eekk:
Ragazzi...lo sapete vero cosa sarebbe successo se un lavoro come quello di oggi l'avessi fatto su un progetto non Test Driven ? Ho risolto le magagne dei vari test ed il gioco ha subito cominciato a funzionare perfettamente...
:eekk: :eekk: :eekk:
Mi sa che è giusto, non hai messo final ;)
Senza final è un membro static e non una costante...e quindi deve iniziare con lettera minuscola...come si vede dal pattern...
CA...PPERACCIO!!!
Hai ragione :flower:
Scusa perchè in Chest non'cè il campo FIRST_FRAME_DELAY ???
Non capisco a cosa serve il colore NULL...
Per le FlashingGem... Le FlashingGem non hanno un colore...quindi le inizializzo a NO_COLOR... In teoria al posto di null ci potevo mettere qualsiasi valore (perchè viene controllato nel costruttore di AbstractDroppable)...ma null mi sembra più significativo di qualsiasi valore :)
Riguardo a FIRST_FRAME_DELAY in Chest...nessuno usava Chest.createForTesting...quindi non ce l'ho messo ;)
Qualcuno ha scoperto perchè il check-style vuole Chest final ??
:wtf: :wtf:
Qualcuno può mettere la BigGem nella gerarchia ? Non ho tempo... E' un lavoro abbastanza grosso, ma vedendo le BigGem come collection di gemme è abastanza semplice...
L'unico problema è che probabilmente serviranno metodi che inseriscono e tolgono le gemme dalla griglia da implementare nella gerarchia (nel caso di "pezzi" singoli si limita a ad inserire/rimuovere una cella, nel caso di BigGem aggiunge toglie tutte le celle)...
Questi metodi andranno ad esempio chiamati quando bisogna aggiornare la cella di un'oggetto della gerarchia (ad esempio si muove nella cella sottostante)...
Bisogna raggiungere un livello di integrazione tale che non debba apparire la parola BigGem in Grid eccetto che per updateBigGem (ma solo per quanto riguarda la creazione di nuove BigGem e l'aggiornamento dell'estensione delle vecchie, a questo ci penseremo dopo con la gestione dei DroppableController)...
L'unica cosa particolarmente ostica secondo me è applyGravity...questo mi fa pensare che potremmo cambiare metodo di memorizzazione della grigla (per non applicare più volte la stessa azione alla stessa BigGem)... Per ora credo che comunque potrebbe bastare passare la cella su cui applicare la gravità ad applyGravity...
Come metodo di memorizzazione mi verrebbe in mente una HashMap con l'hash formato da row * 100 + column...
PS: secondo me andrebbero testati tutti i metodi aggiunti a BigGem e che appartengono all'interfaccia Droppable. Contate che alcuni metodi non devono svolgere azioni
Qualcuno può mettere la BigGem nella gerarchia ? Non ho tempo... E' un lavoro abbastanza grosso, ma vedendo le BigGem come collection di gemme è abastanza semplice...
L'unico problema è che probabilmente serviranno metodi che inseriscono e tolgono le gemme dalla griglia da implementare nella gerarchia (nel caso di "pezzi" singoli si limita a ad inserire/rimuovere una cella, nel caso di BigGem aggiunge toglie tutte le celle)...
Questi metodi andranno ad esempio chiamati quando bisogna aggiornare la cella di un'oggetto della gerarchia (ad esempio si muove nella cella sottostante)...
Bisogna raggiungere un livello di integrazione tale che non debba apparire la parola BigGem in Grid eccetto che per updateBigGem (ma solo per quanto riguarda la creazione di nuove BigGem e l'aggiornamento dell'estensione delle vecchie, a questo ci penseremo dopo con la gestione dei DroppableController)...
L'unica cosa particolarmente ostica secondo me è applyGravity...questo mi fa pensare che potremmo cambiare metodo di memorizzazione della grigla (per non applicare più volte la stessa azione alla stessa BigGem)... Per ora credo che comunque potrebbe bastare passare la cella su cui applicare la gravità ad applyGravity...
Come metodo di memorizzazione mi verrebbe in mente una HashMap con l'hash formato da row * 100 + column...
PS: secondo me andrebbero testati tutti i metodi aggiunti a BigGem e che appartengono all'interfaccia Droppable. Contate che alcuni metodi non devono svolgere azioni
BigGem non è meglio se resta com'è?
IMHO no...altrimenti salta tutto lo snellimento di Grid... Fai conto che integrando BigGem nella gerarchia si arriva a semplificare tutto: i crush, il calcolo dei punteggi, Grid...
Insomma...tratteremo le BigGem come normali Droppable...
Ragazzi...lo sapete vero cosa sarebbe successo se un lavoro come quello di oggi l'avessi fatto su un progetto non Test Driven ? Ho risolto le magagne dei vari test ed il gioco ha subito cominciato a funzionare perfettamente...
:)
Ottimo lavoro.
fek cosa ne pensi di quello che ho scritto sopra su BigGem ?
Secondo me riuscire a non fare distinzione fra Droppable e BigGem sarebbe una notevole semplificazione...
fek cosa ne pensi di quello che ho scritto sopra su BigGem ?
Secondo me riuscire a non fare distinzione fra Droppable e BigGem sarebbe una notevole semplificazione...
Devo guardare il codice stasera per darti una risposta precisa. Hai provato ad iniziare il refactoring? Secondo te?
Ho provato ad inziare... Ho guardato un po' in giro... Secondo me sarebbe fattibile...e sicuramente miglirorerebbe tutto (ovviamente l'effetto desiderato si raggiungerebbe solo quando vengono aggiunti i DroppableController)...
Ho provato ad inziare... Ho guardato un po' in giro... Secondo me sarebbe fattibile...e sicuramente miglirorerebbe tutto (ovviamente l'effetto desiderato si raggiungerebbe solo quando vengono aggiunti i DroppableController)...
Cionci ho un'altra idea...
BigGem non è un droppable... Se per droppable intendi oggetto controllato dall'utente e droppato appunto.
BigGem però può essere un Crushable :)
Sono contrario ad usare un'interfaccia e poi doverla implementare con metodi vuoti perchè quell'oggetto non ha certe caratteristiche.
L'interfaccia deve essere minimale ed astrarre al meglio una certa caratteristica giusto? Possiamo estrarre alcune caratteristiche secondo me... Crushable è una di queste a mio parere :)
Sono contrario ad usare un'interfaccia e poi doverla implementare con metodi vuoti perchè quell'oggetto non ha certe caratteristiche.
L'interfaccia deve essere minimale ed astrarre al meglio una certa caratteristica giusto? Possiamo estrarre alcune caratteristiche secondo me... Crushable è una di queste a mio parere :)
Si', sono d'accordo. Preferisco avere piu' interfacce piu' semplice che una sola molto complessa.
Ed ho appena notato che l'interfaccia Droppable contiene 25 (!!!!!!!!) metodi.
Gia' 5 sono troppi :)
Urge un corposo refactoring di Droppable.
Cionci ho un'altra idea...
BigGem non è un droppable... Se per droppable intendi oggetto controllato dall'utente e droppato appunto.
BigGem però può essere un Crushable :)
Per droppable intendo un qualcosa che cade e si può fermare nella griglia...sicuramente è possibile suddividere l'interfaccia...
Le funzioni vuote sono principalmente quelle relative all'animazione...quindi in teoria sarebbe possibile creare un'interfaccia per gli oggetti "animabili"...
BigGem potrebbe implementare Droppable e non l'altra interfaccia...
Riguardo a Crushable, tutte sono crushable... Potrebbe essere un nuovo nome di Droppable, ma niente di più IMHO...
Per droppable intendo un qualcosa che cade e si può fermare nella griglia...sicuramente è possibile suddividere l'interfaccia...
Le funzioni vuote sono principalmente quelle relative all'animazione...quindi in teoria sarebbe possibile creare un'interfaccia per gli oggetti "animabili"...
BigGem potrebbe implementare Droppable e non l'altra interfaccia...
Riguardo a Crushable, tutte sono crushable... Potrebbe essere un nuovo nome di Droppable, ma niente di più IMHO...
Dunque, bisogna tirare giu' il numero di metodi dell'interfaccia a qualcosa attorno a 5/7. Una strategia potrebbe essere la seguente e cionci e' gia' sulla strada giusta.
Si partiziona l'interfaccia in metodi logicamente collegati, ad esempio un'interfaccia "animabile" (Animated), un'interfaccia propriamente Droppable, un'interfaccia per gli oggetti che si disegnano e restituiscono informazioni sulla posizione (DrawableObject).
Nasce il problema di come passare da un oggetto che noi sappiamo solo essere Droppable alla corrispondente interfaccia, ad esempio DrawableObject, in caso la supportasse.
Se avessimo un'interfaccia "contenitore", ad esempio di nome Item (nome provvisorissimo e banalissimo), si potrebbe chiedere ad un'oggetto che implementa quest'interfaccia se supporta Droppable o Animated, cosi':
Item item = getItem(...);
Droppable droppable = item.getDroppable();
if (droppable != null)
{
// do something with droppable;
}
Animated animated = item.getAnimated();
if (animated != null)
{
// do something with animated;
}
DrawableObject drawableObject = item.getDrowableObject();
{
// do something with drowableObject;
}
Se un particolare item, ad esempio, non e' animato, alla richiesta di interfaccia Animated restituisce null (o magari in seguito un oggetto NullAnimated).
Questo e' cio' a cui dovremmo arrivare per semplificare ulteriormente Droppable a mio avviso.
Poi, come puro esercizio teorico, se volessimo generalizzare quest'approccio potremmo avere un metodo di interfaccia di questo tipo:
BaseInterface getInterface(string interfaceName)
E invocarlo cosi':
Droppable droppable = (Droppable) item.getInterface("Droppable");
Un oggetto che deriva da Droppable potrebbe implementare getInterface() cosi':
BaseInterface getInterface(string interfaceName)
{
if (interfaceName == "Droppable")
{
return this;
}
return null;
}
Volendo si potrebbe prendere getInterface e metterlo in una propria interfaccia BaseInterface o Unknown. Chi indovina che cos'e' questa cosa qui? :)
Soluzione: E' un design pattern chiamato Composite Interfaces ed e' il design pattern implementato da COM.
ottimo...avevo pensato anche io ad una cosa del genere con i NullObject...
Scuate....ma non è un po' reinventarsi la reflection???
:mbe: :mbe:
Scuate....ma non è un po' reinventarsi la reflection???
:mbe: :mbe:
+ o -, ma è probabilmente piu elegante e veloce(e meno potente)
cionci, se domani pomeriggio ci sei sono tutto tuo per questo refactoring.
Credo di sì...ma vediamo...
Fate update del codice, abbiamo fatto sparire sei metodi da Droppable come per magia, e nessuna classe nuova :)
Un paio d'ore di refactoring e il mondo e' un po' piu' bello.
Ora voglio vedere sparire getType(). In un ambiente OO, qualcosa tipo getType non ha senso di esistere perche' si sta cercando di variare il comportamento di qualche azione basandosi sul tipo sotto l'interfaccia. Ovvero, si sta cercando di circumnavigare proprio il motivo per il quale abbiamo messo li' un'interfaccia.
Il problema si trasforma nel trovare i giusti metodi polimorfici di Droppable.
Tradotto: entro stasera getType deve morire :)
Il server è down ?!?!?
Avrei finito... Per ora non ho inserito ancora alcun NullObject perchè tutti le classi implementano le stesse interfacce... Quando inseriremo BigGem potremo sfruttarli per quello...
Fate update del codice, abbiamo fatto sparire sei metodi da Droppable come per magia, e nessuna classe nuova :)
Un paio d'ore di refactoring e il mondo e' un po' piu' bello.
Miii proprio ora che facevo il refactoring :eek: :muro: :muro: :muro:
void useBrighterImage();
void useNormalImage();
boolean isBrighter();
Ma questi metodi a che servono ora ?!?!?
Inoltre stop e drop non fanno la stessa cosa ?
void useBrighterImage();
void useNormalImage();
boolean isBrighter();
Ma questi metodi a che servono ora ?!?!?
Inoltre stop e drop non fanno la stessa cosa ?
In teoria non servono più ma chiederei a Joc.
Riguardo stop e drop fanno la stessa cosa solo che uno la fa con playsound :)
Cosa ne dite di aggiungere una classe Animation che include la lista di Frame, frame corrente e tutte le altre informazioni relative?
In teoria non servono più ma chiederei a Joc.
Riguardo stop e drop fanno la stessa cosa solo che uno la fa con playsound :)
Quindi ce ne serve uno solo dei due.
Cosa ne dite di aggiungere una classe Animation che include la lista di Frame, frame corrente e tutte le altre informazioni relative?
Fai pure :)
Il server è ancora down...
Cosa ne dite di aggiungere una classe Animation che include la lista di Frame, frame corrente e tutte le altre informazioni relative?
Aspetta...perchè devo mettere su il refactoring delle interfacce...
Impossibile stabilire la connessione. Rifiuto persistente del computer di destinazione.
svn: Can't connect to host 'eternal.dnsalias.net': Impossibile stabilire la connessione. Rifiuto persistente del computer di destinazione.
Riguardo stop e drop fanno la stessa cosa solo che uno la fa con playsound :)
public void drop()
{
if(isFalling())
{
stop();
}
}
drop chiama stop quindi l'unica differenza è che chiamando più volte drop, se la gemma è ferma non si ripete il suono... Secondo me stop si può rendere o privata o si può includere in drop...
Aspetta...perchè devo mettere su il refactoring delle interfacce...
pure io :p
Cioè ? Io devo fare l'update di circa una 50ina di file !!!
Ma che è successo al server ?
Cioè ? Io devo fare l'update di circa una 50ina di file !!!
Ma che è successo al server ?
Io ho eliminato alcuni metodi dall'interfaccia... Il refactoring tocca non so quanti file... un po'... asp.. 21 circa :o
Cioè ? Io devo fare l'update di circa una 50ina di file !!!
Ma che è successo al server ?
Stai attentissimo prima del commit, fai un update e il merge, perche' io e Ufo abbiamo cambiato molta roba. Come regola generale non far passare mai piu' di mezz'ora fra un commit e l'altro, cerca di committare sempre a piccoli passi.
Eh lo so, ma il sistema era down... Forse sonoa cnhe di più di 50 :)
Io fra 45 minuti devo andare via...come si fa se il server è ancora down ?
Edit: ora funziona !!!
Io le mie modifiche le ho committate, fai pure update...
Non potevi aspettare ? :cry:
Faccio il revert delle mie modifiche...altrimenti non è possibile recuperare...
Azz mi sa che oltre alle mie ti sei beccato pure tutte quelle di Fra perchè non erano così radicali :P
Avevo più di 30 conflitti...
cdimauro
10-04-2006, 07:25
Stai attentissimo prima del commit, fai un update e il merge, perche' io e Ufo abbiamo cambiato molta roba. Come regola generale non far passare mai piu' di mezz'ora fra un commit e l'altro, cerca di committare sempre a piccoli passi.
E' successo anche a me di trovarmi con una marea di modifiche dopo l'update: sono stato costretto a buttarle via (troppi casini) e rifarle da capo.
Purtroppo a volte mezz'ora per un commit non basta proprio. :muro:
E' successo anche a me di trovarmi con una marea di modifiche dopo l'update: sono stato costretto a buttarle via (troppi casini) e rifarle da capo.
Purtroppo a volte mezz'ora per un commit non basta proprio. :muro:
Quando ho troppi conflitti anch'io butto via e ricomincio. Per questo cerco di ridurre il tempo fra un commit e l'altro.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.