Un'alternativa all'avere campi che potrebbero non essere usati in una classe

2

Sto scrivendo una carta / gioco da tavolo in Java. Dato che il gioco ha molte carte che interagiscono in modi diversi, la mia classe Player è diventata un po 'gonfia con tutti questi diversi campi utilizzati per tenere traccia dei dati di cui hanno bisogno le carte specifiche. Tuttavia, non tutte le carte vengono utilizzate in ogni gioco, quindi molti di questi campi non vengono utilizzati. Invece di avere diversi campi che probabilmente non verranno utilizzati la maggior parte del tempo, stavo pensando di scrivere una sorta di classe di una mappa di campo che potesse "creare" campi dinamicamente quando erano necessari. Se un tipo di carta richiedeva che ogni giocatore memorizzasse alcuni dati in una lista, poteva semplicemente crearne uno e memorizzarlo nella mappa del campo di quel giocatore. Potrebbe essere un po 'complicato, però: che tipi di chiavi dovrei usare? Stringhe? Solo oggetti semplici? E il tipo di dati non sarà sempre un elenco, quindi probabilmente dovrebbe essere Map<String, Object> , e dovrei inserire cast. Le chiavi dovrebbero essere la propria classe la cui identità è basata su un nome String, ma contengono anche un campo Class<?> , in modo che possa generare il risultato per me?

In genere mi piace questa idea, dal momento che significa che non devo scherzare con la classe Player ogni volta che creo una nuova carta, ma sembra anche abbastanza inefficiente e poco elegante. È una pessima idea?

    
posta codebreaker 27.12.2013 - 22:54
fonte

1 risposta

2

Solitamente, lo risolverai usando l'ereditarietà. Avresti una classe genitore Card , con classi derivate con campi specifici per giochi specifici. Questo ti consente di utilizzare raccolte di Card s in codice generico che è riutilizzabile in giochi diversi, ma ti dà comunque il tipo di sicurezza del compilatore nel codice specifico del gioco.

La seconda cosa da considerare è che i campi potrebbero non essere effettivamente appropriati alla classe Card , ma in realtà si adattano meglio a un'altra classe. Ad esempio, in "Hearts" la Queen of Spades ha un comportamento un po 'speciale rispetto alle altre carte, ma puoi controllare questo comportamento nella logica del gioco piuttosto che nella classe Card .

Se veramente non riesci a pensare a un modo di utilizzare l'ereditarietà, aggiungo ancora qualcosa come Map<Card, Integer> points nella classe di un gioco specifico prima di prendere in considerazione la possibilità di inserire un% genericoMap<String, Object> in una Card class. Calcolando sempre una chiave String , quindi il cast del valore del risultato nella classe appropriata diventerebbe noioso e soggetto a errori.

    
risposta data 29.12.2013 - 01:59
fonte

Leggi altre domande sui tag