Decisione di progettazione del gioco di carte Java

Aggiungi una classe Table che contiene diversi Stack s.

Quindi ogni pila è una lista di carte in cui puoi togliere quella superiore e mettere una carta con determinati vincoli.

Lo spostamento di una carta sarà quindi ( destination e source sono Stack s):

if(destination.canPut(source.top())){
    destination.put(source.take());
}

La vista saprà dove e come renderizzare ogni pila e come appaiono le carte ecc.

Quindi il risultato finale è che la Carta è solo un oggetto immutabile stupido contenuto in uno Stack.

Ogni pila può avere diversi vincoli usando il polimorfismo, ad esempio il piatto non può prendere alcuna carta, il risultato può prendere solo carte dello stesso seme e 1 più alto e così via.

La classe Card dovrebbe gestire la propria posizione?

No. Come hai detto tu, una carta è definita esclusivamente dal suo rango e dalla sua suite. Il 10 di Spades rimane il 10 di Spades indipendentemente da dove sia. In effetti, direi che le carte non hanno metodi rilevanti se non quello di ottenere il grado e la causa. (È conveniente definire equals e hashCode come metodi, ma se si ha accesso al rank e al seme è possibile confrontare le carte senza accedere ai loro campi privati.È semplicemente più semplice non dover passare Comparators o whatnot quando ordinamento, ecc. Se fai enumerazioni di carte, questo è gratis.)

Come nota a margine, qui ci sono due concetti separati di posizione. C'è la posizione logica astratta rilevante per la logica di gioco (ad esempio il 10 di Spades è sopra il 4 ° stack da sinistra) e poi c'è la posizione di presentazione (ad esempio il 4 ° stack da sinistra viene disegnato alle coordinate dello schermo 58, 160) . La posizione astratta delle pile appartiene al modello; la posizione di presentazione nella vista.

Ciò non significa che il mio modello non sia disaccoppiato correttamente?

Sì, se si introduce la posizione dello schermo nella classe Card, è stato introdotto l'accoppiamento dal modello alla vista. (L'accoppiamento nell'altra direzione, dalla vista al modello, è normale.) Ad esempio, se si desidera rendere il gioco più elaborato avendo le carte 3D spostate attorno a un tavolo 3D, è necessario modificare la classe Card per contenere 3D punti invece di punti 2D. Non vuoi solo farlo in modo che tu possa cambiare le implementazioni vista scambiando una classe con un'altra: vuoi anche isolare il modello dall'impatto delle modifiche alla progettazione della vista.

Se la vista dovesse gestire la posizione della carta, non creerebbe oggetti e riferimenti eccessivi?

Non vedo come spostare la posizione della carta da uno strato all'altro del programma cambia la quantità di dati di cui tenere traccia. Anche se lo facesse, probabilmente non cambierà il tempo asintotico o l'uso dello spazio del programma. Anche se lo facesse, è troppo presto per preoccuparsi dell'ottimizzazione se non si hanno obiettivi prestazionali chiaramente definiti e un'implementazione che si può misurare. È improbabile che un gioco con così pochi dati da tenere sotto controllo abbia un problema di prestazioni a meno che tu non stia facendo qualcosa di molto, molto sbagliato.