[CICLO 6/bis] Xmas Carol Story 2

[cionci]

Non è detto, ma mi sembrava logico perchè dovrebbe erditarne non solo l'interfaccia, ma anche gran parte del codice... Inoltre in questo modo Grid non andrabbe modificata nemmeno di una virgola (anzi, qualcosa sì, ma solo per le collisioni)...

[fek]

Originariamente inviato da cionci

Sinceramente io avrei visto benissimo una classe GemsPair derivata da Gem con una istanza della gemma slave all'interno...
Continuando così si rende Grid troppo complicato...magari avrebbe dovuto essere il task Xmas.2.0...

"Prefer Composition over Inheritance"

GemsPair "non e' un" Gem. Quindi non deve derivare da Gem.

[cionci]

Sì, ma allora deriviamo PivotGem da Gem...e poi a PivotGem gli passaimo la gemma slave... Cambia il nome, ma il succo è lo stesso...mi sembra che sia necessario ottenere una classe di questo tipo prima di cominciare a lavorare sulle coppie di gemme...

[fek]

Originariamente inviato da cionci

Sì, ma allora deriviamo PivotGem da Gem...e poi a PivotGem gli passaimo la gemma slave... Cambia il nome, ma il succo è lo stesso...mi sembra che sia necessario ottenere una classe di questo tipo prima di cominciare a lavorare sulle coppie di gemme...

Perche' vuoi derivare? Questa classe contiene due gemme, una e' il pivot, l'altra lo slave. E tiene traccia delle due gemme. Secondo me non c'e' bisogno di derivare.

[Ufo13]

Boh io farei un GemsPair che estende Sprite e contiene due Gem

[fek]

Originariamente inviato da Ufo13

Boh io farei un GemsPair che estende Sprite e contiene due Gem

GemsPair "non e' un" Sprite.

http://www.eventhelix.com/RealtimeMa..._principle.htm

The Liskov Substitution Principle of object oriented design states:

In class hierarchies, it should be possible to treat a specialized object as if it were a base class object.

The basic idea here is very simple. All code operating with a pointer or reference to the base class should be completely transparent to the type of the inherited object. It should be possible to substitute an object of one type with another within the same class hierarchy. Inheriting classes should not perform any actions that will invalidate the assumptions made by the base class.

Ogni volta che derivate una classe da un'altra dovete porvi la domanda se il principio di sostituzione si applica. Una specializzazione di un Handler puo' ovviamente essere usata in sostituzione della classe base, mentre un GemsPair no: svolge azioni che invalidano le assuzioni fatte dalla classe base Sprite (infatti contiene due sprite e non uno solo).

[Ufo13]

hmmmm mi chiedo perchè no?

ahhhh ritiro subito la domanda

Volevo dire drawable

[fek]

Ecco l'articolo completo:

http://www.objectmentor.com/resources/articles/lsp.pdf

Nel nostro caso, una funzione che usasse un GemsPair come se fosse uno Sprite, fallirebbe clamorosamente, perche' deve poter sapere di avere a che fare con GemsPair per onorarne il contratto.

E secondo me non e' neanche un Drawable
Le gemme sono disegnate dalla griglia, GemsPair deve solo controllare che scendano in maniera corretta e rispondano agl'input dell'utente.

[Ufo13]

mazza che figo sto sito :o

[Ufo13]

allora perdonami ho scritto senza guardare il codice... In realtà estendendo sprite saprei bene come gestire la cosa...

Secondo me basta tenere 2 Gems e poi implementare Drawable che diciamo esegue il draw delle due Gem nelle corrette posizioni.

[cionci]

Originariamente inviato da Ufo13

Boh io farei un GemsPair che estende Sprite e contiene due Gem

Non sono d'accordo...a quel punto andrebbe estratta anche l'interfaccia di Gem...ed andrebbe poi implementata in GemsPair...

fek: ti spiego perchè voglio derivare... Così come è adesso Grid tutte le operazioni che adesso svolgiamo su Grid andrebbero duplicate... Invece non duplicando queste operazioni e derivando PivotGem da Gem potremmo settare la gemma slave dall'esterno (pivotGem.setSlaveGem(Gem slave)) e mantenendo la struttura attuale di Grid potremmo replicare le operazioni fatte sulla pivotGem all'interno della pivotGem...
Ad esempio:

    public void moveRight(float step)
    {
        super.moveRight(step);
        slave.moveRight(step);        
    }

Eriditare PivotGem è necessario per permettere a Grid di poter lavorare ancora tramite Gem (ad esempio il membro grid rimarrebbe una matrice di Gem)...anche perchè senza dubbio dovremmo ancora poter lavorare sulla gemma singola...

[fek]

Originariamente inviato da cionci

fek: ti spiego perchè voglio derivare... Così come è adesso Grid tutte le operazioni che adesso svolgiamo su Grid andrebbero duplicate... Invece non duplicando queste operazioni e derivando PivotGem da Gem potremmo settare la gemma slave dall'esterno (pivotGem.setSlaveGem(Gem slave)) e mantenendo la struttura attuale di Grid potremmo replicare le operazioni fatte sulla pivotGem all'interno della pivotGem...

Questo e' un'errore abbastanza classico, tanto che ci sto combattendo anche in ufficio. Non si deriva per riutilizzare il codice (eliminare la duplicazione nel tuo caso), ma si deriva sempre e solo per modellare relazioni ISA.

Noi sappiamo programmare quindi seguiamo questo principio

GemsPair, come la giri, non modella una relazione ISA ne' con Gem, ne' con Sprite, ne' con Drawable. E' una semplice classe di controllo di due gemme, un classico esempio di Composizione. E quello implementiamo. Tutto il resto e' un forzare il design verso qualcosa che ci creera' problemi, quindi andiamo per le cose semplici.

Due gemme dentro GemsPair e via.

[Ufo13]

Cionci: sì scusa, leggi il mio post... Mi ero sbagliato... Avevo solo pensato al Draw e così ho pensato "sprite" senza tenere a mente tutto quello che Sprite comportava

Comunque non vedo perchè usare GemsPair in composition dovrebbe limitarci così tanto... Secondo me si può trovare una soluzione semplice anche per quello

[Ufo13]

Originariamente inviato da fek

Questo e' un'errore abbastanza classico, tanto che ci sto combattendo anche in ufficio. Non si deriva per riutilizzare il codice (eliminare la duplicazione nel tuo caso), ma si deriva sempre e solo per modellare relazioni ISA.

Noi sappiamo programmare quindi seguiamo questo principio

GemsPair, come la giri, non modella una relazione ISA ne' con Gem, ne' con Sprite, ne' con Drawable. E' una semplice classe di controllo di due gemme, un classico esempio di Composizione. E quello implementiamo. Tutto il resto e' un forzare il design verso qualcosa che ci creera' problemi, quindi andiamo per le cose semplici.

Due gemme dentro GemsPair e via.

Hmmm forse ho capito come si può fare... Se mettete il task mi offrirei a farlo in pair programming con qualcuno

[cionci]

Originariamente inviato da Ufo13

Comunque non vedo perchè usare GemsPair in composition dovrebbe limitarci così tanto... Secondo me si può trovare una soluzione semplice anche per quello

Semplicemente perchè andrebbe modificata tutta Grid...ma bisognerebbe comunque mantenere la possibilità di gestire una gemma singola...quindi verrebbe un macello enorme...

[cionci]

Originariamente inviato da fek

Questo e' un'errore abbastanza classico, tanto che ci sto combattendo anche in ufficio. Non si deriva per riutilizzare il codice (eliminare la duplicazione nel tuo caso), ma si deriva sempre e solo per modellare relazioni ISA.

Noi sappiamo programmare quindi seguiamo questo principio

GemsPair, come la giri, non modella una relazione ISA ne' con Gem, ne' con Sprite, ne' con Drawable. E' una semplice classe di controllo di due gemme, un classico esempio di Composizione. E quello implementiamo. Tutto il resto e' un forzare il design verso qualcosa che ci creera' problemi, quindi andiamo per le cose semplici.

Due gemme dentro GemsPair e via.

Io no la vedo come GemsPair...io la vedo come PivotGem... PivotGem ha senso derivarla da Gem... PivotGem è la gemma che controlla la slave, quindi ha senso che pivotGem se viene mossa muova anche la gemma slave... Io non ci vedo niente di forzato...

[Ufo13]

Originariamente inviato da cionci

Semplicemente perchè andrebbe modificata tutta Grid...ma bisognerebbe comunque mantenere la possibilità di gestire una gemma singola...quindi verrebbe un macello enorme...

ma non è vero... io penso che bastino poche modifiche

[fek]

Originariamente inviato da cionci

Io no la vedo come GemsPair...io la vedo come PivotGem... PivotGem ha senso derivarla da Gem... PivotGem è la gemma che controlla la slave, quindi ha senso che pivotGem se viene mossa muova anche la gemma slave... Io non ci vedo niente di forzato...

Secondo me non serve neppure derivare PivotGem. Esci dal loop in cui ti sei infilato, questo task e' molto piu' semplice di quanto pensi. Fallo in PP con Ufo e fatelo sulla linea di guida di non derivare nulla. Non serve.

[Ufo13]

hmmm mi va benissimo farlo in pair con cionci ed inizierei anche subito, ma non è meglio se aspettiamo che vicius confermi il task?

[thebol]

allora, la duplicazione era evidente, ma per ora preferivo mantenerla, fare funzionare il tutto(creazione, movimenti ed eventualmente collisioni) per poi proporlo.

D'accordo su fare la classe gemspair come composizione, e se la si implemente considerando la possibilita che controlli una sola gemma(la pivot) il codice non dovrebbe risentirne troppo.

Si puo considerare di estrarre l'interfaccia da gem, generare la classe composite come un proxy di 2 gem, ma non so se ne vale la pena

in effetti gempair si comporta come una gemma(forse) ma non è una gemma...

cmq ditemi se devo testare tutte le collisioni, o questo compito passa a un prox task(magari con in mezzo il refactoring di pairGem). Cosi tolgo il test per le collisioni gia realizzato e implemento correttamente il movimento(i test precedenti secondo me non sono completi, devo creare un altro test per verificare...), e aggiungo l'init e il rilascio di 2 gem alla volta(ma per questo devo implementare per forza la collisione dal basso...)