andygaspar
commented
4 years ago Allora per quello che riguarda l'astrazione tutto ok, come avevamo visto l'avrei dovuto fare comunque. Non credo sia una buona idea tuttavia chiamarlo input frame ed escludere l'end. Il frame è una classe astratta che astrae un frame, non specificatamente solo l'input; infatti può anche solo essere un frame con stampa e basta. Ad esempio, farò certamente (ci hanno giocato dei miei amici e me lo hanno fatto notare) l'aggiunta della possibilità di ricominciare quando si ha finito il gioco. In quel caso anche l'end avrà un input.
Ho fatto del refactoring nelle classi legate a Frame, ho lavorato direttamente nel branch gui per semplicità, in caso ritenga la cosa non vada bene si può tranquillamente fare un reset.
Sostanzialmente non ho toccato il funzionamento ed in buona parte nemmeno il design, semplicemento ho reso il tutto, a mio avviso, più chiaro. Mi spiego, già in ciò che avevi implementato tu era evidente che i frame che leggono input fossero tutti molto simili, mentre l'unico fuori dal coro era EndGame. Mi è quindi sembrato appropriato distinguere questa sottoclasse tramite InputFrame (resa una classe generica in modo tale da poter scrivere il metodo getInput comune a tutti) e spostare qui il metodo waitInput che serve unicamente ai frame che vanno a leggere dell'input.
Fatto ciò ho adeguato GameFrame a tale struttura cambiando il metodo getMove() in inputMove() e spostando la gestione del reset e del end nella gui.