Quale sarebbe l'approccio migliore quando si progettano le seguenti classi applicando modelli di progettazione?OOP Design per le classi di giochi di carte
- Deck-AggiungeCarta, affare, shuffle, getTopCard, removeTopCard, removeAllCards
- mano-AggiungeCarta, RimuoviCarta, getCard, removeAllCards
- DiscardPile-AggiungeCarta, getTopCard , removeTopCard, removeAllCards
- MeldPile-AggiungeCarta, removeAllCards
(Il MeldPile detiene tutte le combinazioni nella tabella.)
Per quanto mi riguarda, penso che il getTopCard
e removeTopCard
sono solo un involucro di getCard
e removeCard
, come basta prendere la prima posizione di una carta e poi passarla a getCard
o removeCard
.
Devo usare la composizione? modello di strategia? o semplicemente creare un'altra classe chiamata CardPile e usarla come classe base della classe precedente? Apprezzo davvero se tu potessi fornire un codice di esempio su questo.
L'approccio migliore è quello di iniziare solo a scrivere il regole del gioco e lascia che il tuo design si evolva in modo naturale. Se hai una domanda specifica, ad es. 'Sto cercando di implementare una regola in cui se un giocatore gioca una carta l'altra gioca deve scartare, quale schema dovrei usare qui?' quello potrebbe essere responsabile –
+1 per "fa evolvere il tuo progetto in modo naturale" – radarbob
Fai attenzione a come devolvere le classi "presenti in natura" in classi di particelle sub-atomiche. Le gerarchie di classi possono andare troppo in profondità con l'elaborazione inutilmente generica e gratuita in corso. Puoi sempre refactoring in un secondo momento se la tua * evoluzione naturale del design * richiede una base più generale da cui derivare nuove funzionalità. – radarbob