Yegolev Learns C# - was Your app's data

[Yegolev]

Back to C#, I have a design question.  I have a Card class that represents a generic card.  When instantiating an object, I want a particular card.  What I imagine can happen is that I pass a string argument to Card and it instantiates that particular card; let's call it The Abyss just for an example.  The constructor needs to know what attributes to give The Abyss.  Would it be fine to have this data stored inside the Card class definition?  Seems like a good idea to me but I seem to flop most often on this part of OOP.

[Murgos]

Not that I do a lot of that type of work but offhand my guess is to create a card Interface (a type of abstract base class) that forces a certain set of generic components that you use on the object and then create child classes for each type of card.

A deck then would consist of strongly-typed card objects that are each treated individually but are all of the same 'type' so that you can create generic containers and such to manipulate them with.

This will then allow you to use introspection to do neat tricks with manipulating things at run-time.  Assuming the point of this exercise is still more toward learning OOP and C#.

Someone else will, I am sure, come along and call me a doodie head but the key-words you need to read up on for this are Introspection, Polymorphism and Interface.

[tazelbain]

I'd put the card stats in xml document or database rather than clutter your class with the data for all your cards and get Moose an' Squirrel.

[schild]

I'd card stats in xml document or database rather clutter you class with the data for all your cards.

What. You should read this sentence aloud.

[Yegolev]

Assuming the point of this exercise is still more toward learning OOP and C#.

It is.  I'll take your direction since I didn't understand much of it.

I'd card stats in xml document or database rather clutter you class with the data for all your cards.

What. You should read this sentence aloud.

If you read it in a Boris Badenoff voice and tack "and get moose and squirrel" on the end, you're fine.

[sidereal]

In Soviet Russia, Card class designs you!

Yegolev, what you want here is a template class.  The template class stores the information about a card that persists from game to game.  The name, the flavor text, the cost, etc.  Then you have a card class that has a reference to its template as well as information that exists for a single game.  Whether it's tapped, counters on it, etc.  So to create a new card you either have a factory or the template base class will have a newCard() method that creates a new Card with itself as a template and returns it.

Something like:

Code:

public abstract class CardTemplate {
   protected int mPower = 0;
   ...

   public Card newCard() {
      Card c = new Card(this);
      return c;
   }
}

public class IWinCardTemplate extends CardTemplate {
   public IWinCardTemplate() {
      mPower = 999;
      mToughness = 999;
      mCost = 1;
      mColor = CardColors.BLACK_AS_THE_DARKEST_NIGHT;
   }
}

public class Card {
   private CardTemplate mTemplate;
   private boolean isTapped;

   public Card(CardTemplate ct) {
      mTemplate = ct;
   }
}

[sidereal]

And the next step would be to make it data-driven instead of hardcoded cards.  So you'd load your templates up from an xml file or whatever.  But for the first few iterations, it's fine to just dump them into classes.

[Morat20]

Not that I do a lot of that type of work but offhand my guess is to create a card Interface (a type of abstract base class) that forces a certain set of generic components that you use on the object and then create child classes for each type of card.

A deck then would consist of strongly-typed card objects that are each treated individually but are all of the same 'type' so that you can create generic containers and such to manipulate them with.

This will then allow you to use introspection to do neat tricks with manipulating things at run-time.  Assuming the point of this exercise is still more toward learning OOP and C#.

Someone else will, I am sure, come along and call me a doodie head but the key-words you need to read up on for this are Introspection, Polymorphism and Interface.

Place them in xml or a database, to echo tazelbain.

You don't want to have to go dig into your code because some card changed from 2 black mana to 3, or to add new cards. What you send your class is a key for the card's DB entry, and the card will then load various attributes from the DB.

Never hard code what you can stick in a DB or xml file (or hell, flat text). Why would you recompile your code whenever you add a new card?

[Margalis]

Data driven is the way to go. I try to code things so that the code itself is just the engine that knows how to follow some rules and all the information comes from some place else.

Even if your cards have very special rules it's better to give those rules names and make them data driven so that you can always mix and match if you ever feel like it.