Porting di jRisk in Python

[sospiro]

allora...ho visto il sequence diagram e non ho nulla da obbiettare....
mentre l'altro non conosco la sintassi che hai usato, quindi non so leggerlo...

ho fatto anch'io un diagramma delle classi, usando un pattern molto comune...
in questo semestre ho fatto un altro progetto molto simile usando questo tipo di progettazione e devo dire che rende molto bene..
le classi con stereotipo "interfaccia" sono le classi che mi diceva Gennaro, quelle che poi vanno estese...ne ho messa una per la interfaccia utente ed una altra per dividere dalla logica principale la logica che permetta di eseguire la giocata: in tal modo è tutto più modulare, ed è semplice scrivere un minimale gioco di risiko funzionante (e quindi testabile) e continuare dopo a scrivere nuovi moduli e funzionalità.

fatemi sapere cosa ne pensate!
ciao ciao

[gennaro]

Ottimo! Ma non ho capito a cosa serve l'interfaccia per la Giocata  ???

[sospiro]

l'interfaccia per la giocata serve nel caso ci siano più tipi di giocatore...
supponiamo ad esempio di avere un tipo di giocatore reale (gestito dall'utente) e un tipo virtuale (gestito dalla cpu)...
quando sarà il turno del giocatore reale la giocata dipenderà dala volontà umana dell'uomo...
quando sarà il turno di un giocatore virtuale la giocata dipenderà da un calcolo algoritmico, e magari potrà anche cambiare a seconda del livello a cui si gioca....

si potrebbe mettere tutto in una classe sola, con un enorme if else if else if ... else ma sarai d'accordo con me che un codice scritto così è poco pratico e poco espandibile....
in questa maniera le parti più personalizzabili sono separate e se ne posso implementare altre anche senza conoscere altro del progetto....

spero di essere stato chiaro...
altrimenti chiedi ancora...
per il resto ti pare sia una cosa fatta bene???

[gennaro]

Ora è un po più chiaro ma voglio sapere ancora una cosa... come avverrà la comunicazione tra il giocatore gestito dall'utente e l'utente stesso? Visto che la comunicazione con l'esterno è gestita da Connector anche Utente implementerà Connector? Spero di essere riuscito a spiegarmi...

[sospiro]

Si si ho capito benissimo...
infatti quello è il problema maggiore di questo approccio.

si potrebbe fare una cosa del genere: definiamo una enumerazione (esiste in python??), ad esempio TipiAzione, i cui elementi saranno tipo ATTACCA, DIFENDI, SPOSTA_ARMATE, etc etc...
definiamo inoltre una classe, facciamo Azione, che contiene negli attributi una variabile TipiAzione e poi altre variabili, come numeroArmate, terrenoPartenza, terrenoDestinazione, etc etc...
La logica, quando è il turno del giocatore, chiama il metodo chiediUtente passando come parametro gli uno o più tipi di azione che può compiere l'utente. a questo punto la Gui chiede all'utente le informazioni necessarie (che azione svolgere, su che territorio, quante armate spostare....), inizializza un oggetto di tipo Azione e lo passa come parametro ad un metodo della logica, che legge la Azione e modifica il tabellone e i giocatori come indicato...

questo metodo è perfetto se l'interfaccia lavora con lo stesso thread della logica, altrimenti bisogna mettere qualche lucchetto qua e la per sncronizzare al meglio il tutto....

un altro modo è non usare una interfaccia per connettere, e fare in modo che la gui legga dalla partita e dai dati tutto il necessario e chiami metodi della logica in base alle sclete dell'utente...
ma qui i problemi sono davvero tanti e la gui conterrebbe parte della logica....

spero di essere stato chiaro...
ciao ciao