View Full Version : BigGem, per gli amici BugGem!
Allora mi stavo mettendo a testare mergeUp e mergeRight (http://www.hwupgrade.it/forum/showpost.php?p=20942596&postcount=124), quando sono esploso :bsod:
E' normale che il costruttore di BigGem sia totalmente sgangerato e probabilmente poco testato?!?
Cosa se ne fa bigGem di essere costrutita con una size 1x1 (anzi bisognerebbe costruirla solo con size 2x2) e poi cosa se ne fa di sapere da quali gemme e' stata creata, e poi che se ne fa dell position della sprite( ultimo parametro Point) a costruzione, che tanto dipenda da row e column passatigli come primi parametri ??
Inoltre BigGem e' un Droppable, e quindi la sua row e column non devo essere gestite a creazione, ma ad inserimento come per le altre droppable.
E poi e' normale che siano pochissimi i testCase che usano questo costruttore?? Vuol dire che tutte le volte che abbiamo problemi con BigGem andiamo a a:
-creare la griglia,
- inserire le gemme
-fare updateBigGem
Insomma.... abbiamo fatto un po' i porcellini :oink: :oink:
Altro che calcio rotante volante, qui ci vuole la sacra tecnica del colpo della capocciata di travertino di Hokuto :muro: :muro:
:D :D :D
Se si puo` cambiare BugGem eliminando le gemme contenute in essa ben venga! Le prime implementazioni le richiedevano ma forse ora...
Allora, come avete capito, secondo me il costruttore di BigGem è "sbagliato".
Quello giusto, per me, è:
public BigGem(DroppableColor color, AbstractEngine engine);
che inizializza una BigGem 2x2 con la sprite corretta e basta.
Il poizionamento della sprite e della BigGem vengono gestiti all'inserimento in grid, come succede per le altre droppable.
Inoltre non è dall'esterno che si aggiungono le gemma alla bigGem e che si cancellano quele assorbite da grid, ma se ne occupa la BigGem, che sa benissimo come fare queste cose.
Anche perchè a prima vista la differenza tra extend e mergeUp/Right non è così chiara.
Ora, per sapere come procedere, devo capire bene dove si vuole andare con il DroppabaleDescriptor (che non è testato :muro: :muro:).
Se l'obiettivo è di avere un Droppabale generico che si comporta in modo diverso in base al descriptor, una specie di "behaviour injection" ( me lo sono inventato adesso, chissa se esiste :sofico: ), allora dobbiamo renderci conto che tutte quele cose brutte (isGem, isStone, isSomthing, isSomethingElse...) probabilmente verrano risolte con il poliformismo in questa classe.
A questo punto mi viene da dire che deve quasi divenatare uno Startegy... in modo tale che quando si dice alla griglia TurnStoneInToGem o qualsiaisi altro "stato", ogni droppable si comporterà in modo diverso in base al descriptor.
Ciò facendo però stiamo semplicemente portando fuori dal concetto di droppable la gerechia di Gem, Stone, Flash e quant'altro, che finirà inesorabilemnte in DroppableDescriptor.
E' questo quello che vogliamo? :what: :what:
In questo caso mi ritornerebbe utile farmi generare la AnimatedSprite direttamente dal descriptor.
Esempio:
public BigGem(DroppableColor color, AbstractEngine engine)
{
super(new DroppableDescription(AbstractDroppableType.BIG_GEM, color), engine);
}
protected AbstractDroppable(DroppableDescription droppableDescription, AbstractEngine engine)
{
this.type = droppableDescription.getType();
this.color = droppableDescription.getColor();
setAnimatedSprite(droppableDescription.createSprite(engine));
}
public AnimatedSprite createSprite(AbstractEngine engine) {
return type.createAnimatedSprite(engine, color);
}
public AnimatedSprite createAnimatedSprite(AbstractEngine engine, DroppableColor color) {
TiledSprite sprite = new TiledSprite(color.createTiledImage(engine), 2, 2);
return new AnimatedSprite(sprite, AnimationDescription.createNullAnimation());
}
Quello sopra è il caso della BigGem.
P.S.: anche AnimationDescriptor non è testato....:muro:
P.P.S.: ehm.... è colpa del coach se mancano i test nei Descriptor. O non ho capito niente io (:eh:), oppure vediamo se si spezza le ditine anche da solo :asd: :asd:
Oh, scherzo.... non mi far bannare :flower:
:D :D :D
Allora, come avete capito, secondo me il costruttore di BigGem è "sbagliato".
Quello giusto, per me, è:
public BigGem(DroppableColor color, AbstractEngine engine);
che inizializza una BigGem 2x2 con la sprite corretta e basta.
Il poizionamento della sprite e della BigGem vengono gestiti all'inserimento in grid, come succede per le altre droppable.
Inoltre non è dall'esterno che si aggiungono le gemma alla bigGem e che si cancellano quele assorbite da grid, ma se ne occupa la BigGem, che sa benissimo come fare queste cose.
Anche perchè a prima vista la differenza tra extend e mergeUp/Right non è così chiara.
Ora, per sapere come procedere, devo capire bene dove si vuole andare con il DroppabaleDescriptor (che non è testato :muro: :muro:).
Se l'obiettivo è di avere un Droppabale generico che si comporta in modo diverso in base al descriptor, una specie di "behaviour injection" ( me lo sono inventato adesso, chissa se esiste :sofico: ), allora dobbiamo renderci conto che tutte quele cose brutte (isGem, isStone, isSomthing, isSomethingElse...) probabilmente verrano risolte con il poliformismo in questa classe.
A questo punto mi viene da dire che deve quasi divenatare uno Startegy... in modo tale che quando si dice alla griglia TurnStoneInToGem o qualsiaisi altro "stato", ogni droppable si comporterà in modo diverso in base al descriptor.
Ciò facendo però stiamo semplicemente portando fuori dal concetto di droppable la gerechia di Gem, Stone, Flash e quant'altro, che finirà inesorabilemnte in DroppableDescriptor.
E' questo quello che vogliamo? :what: :what:
In questo caso mi ritornerebbe utile farmi generare la AnimatedSprite direttamente dal descriptor.
Esempio:
public BigGem(DroppableColor color, AbstractEngine engine)
{
super(new DroppableDescription(AbstractDroppableType.BIG_GEM, color), engine);
}
protected AbstractDroppable(DroppableDescription droppableDescription, AbstractEngine engine)
{
this.type = droppableDescription.getType();
this.color = droppableDescription.getColor();
setAnimatedSprite(droppableDescription.createSprite(engine));
}
public AnimatedSprite createSprite(AbstractEngine engine) {
return type.createAnimatedSprite(engine, color);
}
public AnimatedSprite createAnimatedSprite(AbstractEngine engine, DroppableColor color) {
TiledSprite sprite = new TiledSprite(color.createTiledImage(engine), 2, 2);
return new AnimatedSprite(sprite, AnimationDescription.createNullAnimation());
}
Quello sopra è il caso della BigGem.
P.S.: anche AnimationDescriptor non è testato....:muro:
P.P.S.: ehm.... è colpa del coach se mancano i test nei Descriptor. O non ho capito niente io (:eh:), oppure vediamo se si spezza le ditine anche da solo :asd: :asd:
Oh, scherzo.... non mi far bannare :flower:
:D :D :D
Ovviamente se testi una classe a colpi di refactoring ti esce non testata. O meglio ti esce testata indirettamente.
In teoria la "potenza di testing" rimane la stessa (a meno di non aggiungere funzionalita`).
L'unico problema e` che i test sono indiretti e quindi difficili da identificare.
Quando ho estratto AnimatedSprite da AbstractSingleDroppable la classe non aveva test. Alcuni li ho dovuti scrivere a manina ma altri li ho semplicemente trovati rovistando in altri file. Comunque quelle due classi hanno bisogno dei loro test case :P
Allora, come avete capito, secondo me il costruttore di BigGem è "sbagliato".
Quello giusto, per me, è:
public BigGem(DroppableColor color, AbstractEngine engine);
che inizializza una BigGem 2x2 con la sprite corretta e basta.
Il poizionamento della sprite e della BigGem vengono gestiti all'inserimento in grid, come succede per le altre droppable.
Perfetto. Fai pure. Ieri mi sono limitato a semplificare il costruttore ma senza cambiarne comportamento.
Ora, per sapere come procedere, devo capire bene dove si vuole andare con il DroppabaleDescriptor (che non è testato :muro: :muro:).
DroppableDescription e AnimationDescription sono due mie creazioni :D
Sono due value type, hanno semantica puramente di valore (anche se in Java non puo' essere forzata). In parole povere contengono solo dati, sono copiabili, non hanno comportamento. E senza comportamento non c'e' nulla da testare :)
Quindi anche in futuro rimarranno tali. Ho provato a spostare un createImage in DroppableDescripton ma rompe la mia idea di semantica di valore, infatti avrebbe bisogno di un test diretto che non ho scritto, perche' era un semplice tentativo di refactoring, che non mi sta piacendo.
Le classi Description NON sono degl strategy e non lo devono diventare.
P.P.S.: ehm.... è colpa del coach se mancano i test nei Descriptor. O non ho capito niente io (:eh:), oppure vediamo se si spezza le ditine anche da solo :asd: :asd:
Oh, scherzo.... non mi far bannare :flower:
:D :D :D
Value type = no behavior = no test :D
Ovviamente se testi una classe a colpi di refactoring ti esce non testata. O meglio ti esce testata indirettamente.
In teoria la "potenza di testing" rimane la stessa (a meno di non aggiungere funzionalita`).
L'unico problema e` che i test sono indiretti e quindi difficili da identificare.
Qui si scontrano due necessita':
1- Testare una classe che esce dal refactorinng per avere test diretti
2- Non scrivere decine di test ridondanti che complicano solo il codice, vanno mantenuti e non ci aggiungono copertura
Purtroppo non c'e' una risposta univoca, dipendera' da situazione a situazione. Noi propenderemo comunque per il testare, a parte casi nei quali i test gia' esistenti che coprono quella classe sono abbastanza semplici e a basso livello.
Quando ho estratto AnimatedSprite da AbstractSingleDroppable la classe non aveva test. Alcuni li ho dovuti scrivere a manina ma altri li ho semplicemente trovati rovistando in altri file. Comunque quelle due classi hanno bisogno dei loro test case :P
Sono value type, non c'e' niente da testare!
Che senso avrebbe testare se il numero 5 e' proprio il numero 5? :)
Non ho il codice sottomano ma mi pare che abbiano dei getter. Per me i getter si possono testare... Magari e` overkilling ma di solito testiamo tutto..
Perfetto. Fai pure. Ieri mi sono limitato a semplificare il costruttore ma senza cambiarne comportamento.
Ok ;)
... perche' era un semplice tentativo di refactoring, che non mi sta piacendo.
Vuol dire che i descriptor spariscono, o solo il createImage???
Value type = no behavior = no test :D
Imparo, imparo, imapro :ave: :ave:
Non ho il codice sottomano ma mi pare che abbiano dei getter. Per me i getter si possono testare... Magari e` overkilling ma di solito testiamo tutto..
E' un value type! Io neppure ci metterei i getter! Ma poi checkstyle si arrabbia.
Fatto! :yeah:
Adesso BigGem assomiglia molto di più ad un droppabale!!
Ora si costruisce una gemma con un determinato colore e una area 2x2.
Quindi per costruire gemme non c'è più bisogno di fare qui mandrubbi insert2x2Block, insertBigGem, updateBigGem e chi più ne ha più ne metta... Ora basta fare:
BigGem bigGem = new BigGem(DroppableColor.DIAMOND, engine);
grid.insertDroppable(bigGem, row, column);
Per averele più grandi basta fare
singleGem.getRegion().setColumn(column);
singleGem.getRegion().setRow(row);
bigGem.addGem(singleGem);
assertEquals(6, bigGem.getArea());
Dove row e column rappresentano la celle fino alla quale volete far espandere la BigGem.
Volendo si può aggiungere un costruttore con width e height.
Ora tutti a mettere a posto i test!!! (io vado a letto :D :D)
Ho cercato anche di eliminare le included gems.
Verebbe anche bene, se no per il fatto che BigGem vorrebbe eliminare le gemme appena le accorpa, ma così ci si becca la ConcurrentModificationException.
Per adesso ho lascito così, ma quella lista lì deve sparire!! :muro:
Viene usata solo in updateBigGems() di Grid.
O mettiamo in bigGem un metodo clearIncludedGems(), oppure aggiungiamo uno stato che non fa nient'altro che iterare la grid e pulirla dalle gemme segnate come da eliminare o con un flag ( che fa schifo) o con un lista.
Io voto per il metodo clearIncludedGems() ;)
Fatto! :yeah:
Adesso BigGem assomiglia molto di più ad un droppabale!!
Ora si costruisce una gemma con un determinato colore e una area 2x2.
Quindi per costruire gemme non c'è più bisogno di fare qui mandrubbi insert2x2Block, insertBigGem, updateBigGem e chi più ne ha più ne metta... Ora basta fare:
BigGem bigGem = new BigGem(DroppableColor.DIAMOND, engine);
grid.insertDroppable(bigGem, row, column);
Per averele più grandi basta fare
singleGem.getRegion().setColumn(column);
singleGem.getRegion().setRow(row);
bigGem.addGem(singleGem);
assertEquals(6, bigGem.getArea());
Dove row e column rappresentano la celle fino alla quale volete far espandere la BigGem.
Volendo si può aggiungere un costruttore con width e height.
Ora tutti a mettere a posto i test!!! (io vado a letto :D :D)
Hmm non mi piace la bigGem che si espande se aggiungi una Gem... Molto meglio se aggiungi una Region con le caratteristiche giuste (non basta una region 1x1 per esempio).
Ottimo lavoro comunque :D
Bel lavoro Bonfo! E' elegantissimo.
Hmm non mi piace la bigGem che si espande se aggiungi una Gem... Molto meglio se aggiungi una Region con le caratteristiche giuste (non basta una region 1x1 per esempio).
Ottimo lavoro comunque :D
Anche secondo me. Metterei un metodo che espande aggiungendo una che delega il lavoro ad un metodo che espande aggiungendo una region. Ma solo se il secondo serve a semplificare qualche pezzo di codice o test. Altrimenti va bene la sola gemma.
Ho cercato anche di eliminare le included gems.
Verebbe anche bene, se no per il fatto che BigGem vorrebbe eliminare le gemme appena le accorpa, ma così ci si becca la ConcurrentModificationException.
Per adesso ho lascito così, ma quella lista lì deve sparire!! :muro:
Viene usata solo in updateBigGems() di Grid.
O mettiamo in bigGem un metodo clearIncludedGems(), oppure aggiungiamo uno stato che non fa nient'altro che iterare la grid e pulirla dalle gemme segnate come da eliminare o con un flag ( che fa schifo) o con un lista.
Io voto per il metodo clearIncludedGems() ;)
Francamente non mi piace nessuna delle due idee. Cercherei un meccanismo piu' semplice ed elegante che non e' costretto ad esporre questo meccanismo interno.
In Grid esiste gia` removeGem. Basta chiamarlo da BigGem per le gemme incluse...
Secondo me quella lista da qualche parte ci deve essere, non può sparire. Era "cattiva" quando se ne faceva un uso assurdo, ma è ovvio che se vuoi allargare la BigGem devi eliminare le gemme adiacenti, e non puoi farlo in concomitanza con il loro rilevamento o ti becchi la concurrent...
Certo, non va passata da oggetto a oggetto, andrebbe semplicemente creata, usata e "salutata" all'interno di uno stesso metodo.
Ad esempio, non si potrebbe delegare a UpdateBigGems il piccolo onere (per lei) di trovare ed eliminare le gemme, e invece far fare a BigGem solo la sua estensione tramite una Region?
Mi sembra complicato.
La soluzione semplice, secondo me, e` questa:
- Grid non contiene alcuna lista (in questo caso le Gem diventate BigGem) se non i Droppable contenuti
- BigGem mentre si estende si segna le gemme da eliminare in una lista
- Alla fine di ogni estensione BigGem itera la lista e chiama, per ogni gemma, grid.removeDroppable(gem);
Non funzionerebbe cosi`? Non ho il codice sotto mano...
Mi sembra complicato.
La soluzione semplice, secondo me, e` questa:
- Grid non contiene alcuna lista (in questo caso le Gem diventate BigGem) se non i Droppable contenuti
- BigGem mentre si estende si segna le gemme da eliminare in una lista
- Alla fine di ogni estensione BigGem itera la lista e chiama, per ogni gemma, grid.removeDroppable(gem);
Non funzionerebbe cosi`? Non ho il codice sotto mano...
Mi piace molto. Ed abbiamo anche un volontario. Tu :)
Mi sembra un task da fare in pair e in TDD. Stasera dovrei tornare a casa presto e ci possiamo pensare assieme.
molto pene. ma è una mania quella di fregarmi le battute :mc:
e dire che questa non l'avevo neanche mai scritta sul forum :D
Mi sembra complicato.
La soluzione semplice, secondo me, e` questa:
- Grid non contiene alcuna lista (in questo caso le Gem diventate BigGem) se non i Droppable contenuti
- BigGem mentre si estende si segna le gemme da eliminare in una lista
- Alla fine di ogni estensione BigGem itera la lista e chiama, per ogni gemma, grid.removeDroppable(gem);
Non funzionerebbe cosi`? Non ho il codice sotto mano...
Ehm.... questa era la mia idea per clearIncludedGems() !!! :D :D
EDIT:
aspetta, ho capito cosa vuoi dire... cosi' pero' ti becchi la ConcurrentException!
Si potrebe provare un approccio lazy dove grid si limita a registrare le gemme da cancellare, ma la cancellazione avviene alla fine del ciclo. Una specie di GarbageCollector di gemme. Funziona se lo stato di Grid non deve essere valido immediatamente.
penso che la garbage collection sia la soluzione...
Si potrebe provare un approccio lazy dove grid si limita a registrare le gemme da cancellare, ma la cancellazione avviene alla fine del ciclo. Una specie di GarbageCollector di gemme. Funziona se lo stato di Grid non deve essere valido immediatamente.
E questa era la mia seconda idea :D :D
jappilas
07-02-2008, 20:57
Si potrebe provare un approccio lazy dove grid si limita a registrare le gemme da cancellare, ma la cancellazione avviene alla fine del ciclo. Una specie di GarbageCollector di gemme. Funziona se lo stato di Grid non deve essere valido immediatamente.quindi un GridController State in più (forse riciclabile per le Crush) per rimuovere i blocchi di gemme in sospeso ?:stordita:
Ho implementato la garbage collection in TDD. Bonfo puoi convertire l'update di BugGem per usare la nuova lista?
Io sto finendo di rifattorizzare le Action e devo usarla per le crush. Faccio oggi :)
^TiGeRShArK^
10-02-2008, 18:56
Ehm.... questa era la mia idea per clearIncludedGems() !!! :D :D
EDIT:
aspetta, ho capito cosa vuoi dire... cosi' pero' ti becchi la ConcurrentException!
mmm.. perchè si becca quell'eccezione?
viene scatenata che io ricordi solamente quando si sta scorrendo una Collection con un iteratore esplicito o implicito (come nel caso del foreach) e si rimuovono degli elementi da quella stessa collection.
Se però striamo iterando su una lista e chiamando un metodo di ogni elemento non dovrebbe esserci alcun problema... o sbaglio?
usiamo la lista garbage e bom
il fatto è che il metodo chiamato su ogni elemento è grid.removeDroppable(), che quindi interviene proprio sulla lista
EDIT: chissà ufo di quanto mi hai bauttuto, io voto meno di 20 secondi :D :D
^TiGeRShArK^
10-02-2008, 21:09
il fatto è che il metodo chiamato su ogni elemento è grid.removeDroppable(), che quindi interviene proprio sulla lista
EDIT: chissà ufo di quanto mi hai bauttuto, io voto meno di 20 secondi :D :D
ok..
allora basta usare il normale ciclo for al posto del foreach per risolvere il problema :p
Ho implementato la garbage collection in TDD. Bonfo puoi convertire l'update di BugGem per usare la nuova lista?
Io sto finendo di rifattorizzare le Action e devo usarla per le crush. Faccio oggi :)
Fatto!
garbegeCollectDroppables per adesso viene usato solo da gird... potrebbe diventare privato.
Anche perchè se rimarrà sempre così, overo usato solo da grid, si potrebbe ritornare ala semnatica vecchia (ovvero removeFromGrid) e poi ci pensa grid a gestiri le cose internamente.... ma per adesso è ancora troppo presto ;) ;)
Per caso riesci a far diventare questa:
for (Droppable droppable : droppableList)
{
MergingObject extensibleObject = droppable.getMergingObject();
if (extensibleObject != null)
{
extensibleObject.extend(this);
}
}
Una droppableIteration in TDD?
Mi sto già riniziando a perdere nel codice.
Che differenza c'è tra runIteration() e doIteration()??
Non potremmo semplificare un po' di più la code-base? A me gli iteration ricordano molto, se non troppo, le action.
Secondo me ci sono alcuni punti sovraingegnerizzati.. :uh:
Non hai letto il post che avevo scritto? :P
doIteration deve sparire mentre runIteration e` quella nuova, piu` semplice, scritta in TDD. Devi solamente scrivere un metodo per avere la tua iteration funzionante. Inoltre la garbage collection e` eseguita al termine di ogni iterazione cosi` non ti devi preoccupare a
Al momento non capisco cosa ci sia di sovraingegnerizzato.
Le iteration servono a rimuovere il codice da Grid e spostarlo altrove (vedi GameTurn).
Fammi sapere se hai idee per semplificare ulteriormente il sistema :P
Forse mi sto perdendo la visione d'insieme. :doh:
L'idea, correggi se sbaglio, e' di creare GameTurn che diventi il "manager" degli stati e quindi chiami le iteration nell'ordine giusto e gridController diventa solo I/O e grid un "semplice" elenco di gemme??
Ma quindi ad ogni stato corrispondera' 1 iteratrion??
No, le iteration sono semplicemente delle utilità, non gestiscono nulla del gioco, fanno la loro piccola iterazione, la fanno bene e basta, senza conoscere nulla del resto.
La logica di gioco verrà gestita da GameTurn che realizzerà le crush, gestirà gli stati etc.
Grid diventerà un semplice elenco di Droppable con tutti i metodi che servono a inserire / togliere / modificare quegli oggetti (e sembra che non saranno giusto due o tre...)
Almeno, questo è quello che ho capito io :D
Si` baol ha capito bene. Le iteration devono essere semplici semplici.
Si` baol ha capito bene. Le iteration devono essere semplici semplici.
Appunto, no e' che sono troppo semplici?!?
Una classe con 1 metodo con 2 righe dentro... insomma mi sembra che ci stiamo complicando la vita, ma forse mi sbaglio. ;)
Pero' ho le orecchie che mi fischiano... KISSsssssss.....
:D :D
Ma una classe con un solo metodo di un paio di righe non merita di vivere di vita propria.
Beh, quelle iteration introdotte hanno semplificato di molto il codice, se qualcuno riesce a ri-eliminarle semplificando ulteriormente ben venga :D
Ma una classe con un solo metodo di un paio di righe non merita di vivere di vita propria.
Ti faccio una lista dei motivi per usare le iteration:
Molto facile da testare usando mock e indipendentemente da Grid.
Se rimuovi un'iteration devi aggiungerla come metodo pubblico in Grid. Questo significa aggiungere un metodo pubblico ogni volta che ti serve qualcosa tipo "moveDownDroppables" e "canAnyDroppableBeCrushed" e qualsivoglia.
Se non vuoi aggiungere metodi pubblici in grid allora devi rendere pubblica la Droppable List distruggendo l'incapsulazione di Grid.
Se cambia l'implementazione interna di Grid non dovremo mai preoccuparci delle varie Iteration.
Per me iteration sono assai meglio e comunque l'estrazione delle varie iteration e` il primo passo verso la semplificazione di Grid.
Sono comunque abbastanza convinto che dopo i vari refactoring dei Droppable alcune delle Iteration piu` semplici spariranno a favore di un command pattern.
Ho cambiato l'extend() di BigGem. :D
Devo ammettere che la soluzione deve ancora essere migliorata perchè per adesso fa un po' schifo. :(
Ma probabilmente è perchè sono stanco e non ci sono stato sopra abbastanza... con un po' iterazioni di refactoring dovrebbe migliorare molto e probabilmente si può mettere a posto anche merge().
Nota di servizio: il metodo isGemValid() è copiato pari pari da CreateNewBigGemsAction, quindi c'è del codice duplicato.
Nel caso la soluzione sia peggiorativa di quella precedente revertate pure !!
Ho cambiato l'extend() di BigGem. :D
Devo ammettere che la soluzione deve ancora essere migliorata perchè per adesso fa un po' schifo. :(
Ma probabilmente è perchè sono stanco e non ci sono stato sopra abbastanza... con un po' iterazioni di refactoring dovrebbe migliorare molto e probabilmente si può mettere a posto anche merge().
Nota di servizio: il metodo isGemValid() è copiato pari pari da CreateNewBigGemsAction, quindi c'è del codice duplicato.
Nel caso la soluzione sia peggiorativa di quella precedente revertate pure !!
Hmmm gli dai un altro colpetto stasera?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.