Nella vostra discussione, un po' arzigogolata (ma essendo alle prime armi, non potrebbe essere altrimenti) ho notato una debolezza concettuale di base:
voi parlate di 'manoUmana' e 'manoComputer' (ed altri esempi del genere) come degli oggetti distinti.
Dal punto di vista della programmazione ad oggetti, questa non e' una gran scelta: porta a diverse problematiche di modellazione, abbastanza complicate da descivere in un singolo post. Inoltre mescola concetti che non hanno nulla a che fare tra di loro:
1) i giocatori (umano, computer)
2) i valori giocati (mano, ...)
3) la parte visiva e di interazione con la tastiera o l'interfaccia utente)
Vi propongo un diverso approccio:
vi serve una 'classe' 'giocatore', quindi due 'istanze' di tale classe: una per il giocatore 1 (l'essere umano, ma non necessariamente ) ed una per il giocatore 2 (il computer ?)
la classe 'giocatore' avra' il metodo 'gioco()' che ritorna 'sasso', 'forbice', 'carta' (oppure 0,1,2)
ora vi serve una classe 'arbitro' e la relativa 'istanza' (una sola).
La classe 'arbitro' che cosa fa?
1) chiede chi sono i due giocatori
2) decide quando iniziare la partita e quanto deve essere lunga (n di giocate)
3.1) chiede al primo giocatore di giocare (chiama il metodo 'gioco()' del primo giocatore)
3.2) chiede al secondo giocatore di giocare (chiama il metodo 'gioco()' del secondo giocatore)
3.3) confronta le giocate e decide il vincitore
4) mostra l'andamento della partita
Ovviamente esistera' un'unico arbitro, quindi un 'singleton' (e 'design pattern' )
Ed ora la parte un pochino piu' complicata.
La classe 'giocatore' e' generica, nel senso che non e' suo compito sapere come varra' fatta la giocata
(come sara' 'implementato' il metodo 'gioco()')
In questo caso ci sono due tipi di 'giocatori':
1) il 'giocatore' 'umano' (classe 'giocatoreUmano') in cui il metodo 'gioco()' viene implementato leggendo la giocata da tastiera o mediante un pulsante
2) il 'giocatore' 'computer' (classe 'giocatoreComputer') in cui il metodo 'gioco()' viene implementato mediante un generatore di numeri casuali che ritorna 0,1 o 2
La classe 'giocatoreUmano' e 'giocatoreComputer' sono delle 'sottoclassi' di 'giocatore'.
La classe 'arbitro' non ha nessuna necessita' di sapere come sono fatti i due giocatori !
Ed infatti, potreste inventare anche il 'giocatoreCostante' (sempre sottoclasse di 'giocatore') in cui il metodo 'gioco()' ritorna SEMPRE la stessa giocata (se ci pensate un po', non vi sevono 3 classi distinte, cioe' una per 'sasso', una per 'forbice' ed una per 'carta')
Nota: questo gioco ha una proprieta' molto particolare
Le regole del gioco dicono che:
a) sasso vince su forbice
b) forbice vince su carta
c) carta vince su sasso
supponendo di rappresentare i tre elementi con dei numeri, con la regola che:
A vince su B se A e' maggiore di B
allora vi trovate in una situazione IMPOSSIBILE DA RAPPRESENTARE CON I NUMERI: partiamo con 'sasso' rappresentato dal numero 2, cosi' da partire dalla regola a)
sasso -> 2
forbice -> 1
carta -> 0
con questa assegnazione di valori, risolvete le regole a) e b), ma non la c) (0 NON E' MAGGIORE DI 2)
Il problema e' evidentemente la 'circolarita' ' delle vincite che non e' rappresentabile con i numeri interi.
Quindi lo switch e' l'unica soluzione possibile.
Nota: piu' che il 5/10%, direi lo 0.00005/0.00010% .
Ma finche' non si trova il modo di 'nascere imparati' o acquisire la conoscenza mediante iniezione per endovena, l'unico modo per imparare e': studiare/fare/sbagliare/studiare/fare/sbagliare/...
In modo 'circolare', come per il gioco