Progettazione di entità per un gioco di blackjack - dovrei fare di Card un'entità?

Question

Progettazione di entità per un gioco di blackjack - dovrei fare di Card un'entità?

#1 da (1 voti)
#2 da (0 voti)

0

Sto creando un semplice gioco di blackjack supportato dal database

Nella mia carta è

public class Card{
 private Face face;
 private Suit suit;

 //setters.. getters
}

dove face e suit sono enumerazioni

Ho un'entità Bet con il seguente

@Entity
public class Bet{
   private Player player;
   private String cards;
   //...
}

Attualmente, quando sto distribuendo le carte, analizzo la tuta e la faccia in una stringa e le concateno nel campo delle carte e poi analizzo le carte se voglio calcolare il punteggio. Trovo questo ingombrante, quindi voglio cambiare le mie "carte" del campo in "Elenco" nell'entità della scommessa.

Ora, se così fosse, dovrei fare di una classe anche la classe Card. Ma il mio cardService , che è dove ottengo le mie carte, non si basa sul database, crea solo carte casuali quindi non ha senso fare di una carta un'entità - ho ragione?

domain-model hibernate entity

posta user3308224 11.09.2014 - 09:39

fonte

2 risposte

1

È una decisione di progettazione. Puoi rendere Card un'entità, con attributi come rank, suit, blackjack value (1..11), ecc. E guidare il gioco dai dati. Ciò ti consente di modificare il gioco modificando i dati e ti consente di produrre un rapporto utile sul gioco dal solo database.

Oppure potresti rendere Card una classe di valore (enum o qualsiasi altra cosa) e specificare come verrà tradotta in / da un valore numerico o stringa nel database. A seconda di come rappresenti le carte nel database, potrebbe essere più difficile generare un rapporto indipendente dal codice dell'applicazione.

risposta data 11.09.2014 - 19:19

fonte

Leggi altre domande sui tag domain-model hibernate entity

Caricamento elaborazione dello schizzo con libreria su github Dato un albero che calcola Max Sum da cima a fondo facendo causa a DFS? ottimizzazione?

score 0 · Accepted Answer

Una carta è un valore, non un'entità.

Le carte non hanno identità - se il pacchetto contiene due carte con lo stesso valore non è interessante identificarle separatamente. Hanno solo valore.

I linguaggi di programmazione tendono a fornire valori come integer, string e struct. Devi scegliere uno di quelli per rappresentare il valore di una carta. Suggerirei di usare un intero per il valore e scrivere una classe in grado di convertire tale numero intero da e verso la rappresentazione di stringa o immagine e di restituire il rango, il seme e l'ordine (che potrebbe non essere uguale all'ordine intero).

Quindi il generatore genera semplicemente numeri interi all'interno di un intervallo specificato.

Il solito mazzo di carte contiene 53 carte distinte, incluso un Jolly. Ci sono giochi (500) che hanno fino a 63 carte distinte ma il principio è lo stesso, e un intero è un modo perfettamente conveniente per codificare il valore. Lo userei anche nel database.

Per una mano o un affare hai più carte, fino a 13 in Bridge o 52 se vuoi mantenere un accordo completo. Potresti codificarlo come un elenco separato da spazi di interi o in un altro modo, a seconda di ciò che ti serve. Sta scendendo dal punto originale.

Per chiarezza, non suggerisco per un momento che si debbano usare interi effettivi nel codice per rappresentare le carte. In Java o JavaScript vorrei usare una classe, in C # o C ++ una struct. Il problema è che un oggetto ha identità, ma vogliamo occuparci dei valori. Vogliamo due diversi oggetti di carte che hanno lo stesso valore per essere uguali. Il modo più semplice (ma non l'unico modo) per farlo è che l'oggetto della carta contenga un numero intero in modo che due carte con lo stesso valore intero abbiano lo stesso valore. Questo viene fatto implementando un operatore 'Confronta uguale' nella classe che confronta il valore intero.

Questo è un problema sottile, la rappresentazione dei tipi di valore, e non è facilmente indirizzabile con un pubblico con competenze molto diverse.