Creating cards for a card game

Question

So I'm playing with the idea of putting together a simple battle card playing game and am running up against a data/code issue. In the game will be various Cards (potentially hundreds). Each card will have some data describing various its strengths and it may also have complex methods that handle what happens when you play the card.
(I'd like each Card implementation to represent what the card does, as opposed to who may hold a particular copy of it. For example, I'd like to have a unique JackOfDiamondsCard object that represents info specific to the card. I may then have several Hands that contain CardInstance objects, some of which may have a reference to the unique JackOfDiamondsCard object. Thus the JackOfDiamonsCard could appear in multiple hands.)
At first glance it's a simple case of having a root Card class and hundreds of children that fill out the details. However, this has the problem that I can create many instances of the same card, which both seems like a waste of memory (since all instances would have exactly the same data) and would make equals() and hashCode() give different results for different instances of the same card.
One way around this is to put all the cards together into a single enum, but that would quickly grow to an unmanagable (and unreadable) size. I'd also like to be able to group the cards into different packages, or maybe even spread them across several jars.
Another way may be to turn each card into a singleton and then build an index of all the cards in the jar (maybe using @annotations?) This seems kind of complicated, though, and writing all those singletons would make for a lot of boilerplate in each card class.
Any ideas on a good way to tackle this? Are singletons the way to go or should I put up with potentially multiple copies of the same card object floating around?

Answer 1

Mark_McKay wrote:
The problem is that I need the overriding classes to provide some fairly complex code for each card. In a battle card game, there may be several different things in play that each card could alter in a wacky way. One card may give the player more 'energy points'. Another may strike the opponent with lightning damage. A third may cause one player to randomly steal a card from the other player. A fourth could set up some sort of defense barrier. The wide (and unpredictable) range things that each card may do prevent me from creating just one generic card class. (Although that would work well if the cards only differed by their data).Allow me to introduce some friends of mine. Probably the first one is going to be easiest for you to understand and get working quickly. The last one, probably only any use in conjunction with one of the others here.
This wacky behaviour is really just another property of the card, like it's suit, or name, or whatever. Behaviours, like data, can often be assigned to objects at runtime, rather than expressed with unweildy inheritance trees.