2

I'm writing a card/ board game in Java. Since the game has lots of cards that interact in different ways, my Player class has become sort of bloated with all these different fields used for keeping track of data that specific cards need. However, not every card is used in every game, so many of these fields are not used. Instead of having several fields that probably won't be used a majority of the time, I was thinking of writing sort of a field map class that could dynamically "create" fields when they were needed. If one type of card required each player to store some data in a List, it could just create one and store it in that player's field map. It could get a little messy, though: what types of keys should I use? Strings? Just plain Objects? And the type of data won't always be a List, so it would probably have to be Map<String, Object>, and I would have to put in casts. Should the keys be their own class whose identity is based on a String name, but also contain a Class<?> field, so that it could cast the result for me?

I kind of like this idea, since it means I don't have to mess with the Player class every time I make a new card, but it also seems kind of inefficient and inelegant. Is this a terrible idea?

|improve this question
  • 1
    Well, as I said, there's a bunch of them and they're annoying to keep track of. And also, it would be nice if the logic for each card could just be part of the card. It makes it easier to modify if I don't have to change other parts of the game logic. It's not a big deal to have unused fields, but I want to see if there are any alternatives. – codebreaker Dec 27 '13 at 22:15
  • 2
    Your idea is called Entity-attribute-value model (see en.wikipedia.org/wiki/…). But honestly, from what you wrote - without any useful example - I cannot tell you if that is the right design decision. – Doc Brown Dec 27 '13 at 22:48
  • 2
    Maybe you can clarify your question: Do you want to know, if your proposed solution is a "terrible idea" in general? Or in comparison to having many optional fields? (Or do you want to know alternatives to your solution?) – Benni Dec 28 '13 at 17:24
  • 1
    It sounds to me like you've just designed the entire program as a bunch of unstructured variables and procedures instead of thinking about ways to (de)compose the problem. What you're proposing is almost certainly going to make things even worse than they already are. Interactions between objects or types should be modeled as part of those objects or types, and therefore objects that aren't in use won't require any extra variables because they won't have been instantiated. – Aaronaught Dec 29 '13 at 2:05
  • 1
    The "dynamic creation of fields" either gets into a degree of metaprograming that Java doesn't have or the use of Maps and the Entity-attribute-value model mentioned above. – user40980 Dec 29 '13 at 3:40
2

Typically, you would solve this using inheritance. You would have a Card parent class, with derived classes with specific fields for specific games. This lets you use collections of Cards in generic code that is reusable across different games, but still gives you the type safety of the compiler in game-specific code.

The second thing to consider is that the fields might not actually be appropriate to the Card class, but actually fit better in another class. For example, in "Hearts" the Queen of Spades has somewhat special behavior compared to other cards, but you could check for that behavior in the game's logic rather than the Card class.

If you really can't think of a way to use inheritance, I still would put something like a Map<Card, Integer> points in a specific game's class before considering putting a generic Map<String, Object> into a Card class. Always calculating a String key, then casting the result value to the appropriate class would get tedious and error prone.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.