0

I have a game I am making that has a current class hierarchy of GenerateStats -> ClassStats -> CreateCharacter. I feel as though this may be going backwards. Stats don't have class stats, and class stats do not have characters. Am I going backwards? Should it be CreateCharacter -> ClassStats -> GenerateStats? Thank you for your input!

Ry-
  • 218,210
  • 55
  • 464
  • 476
user1056607
  • 55
  • 6

4 Answers4

9

None of these make sense in a class hierarchy; class hierarchies represent "is a kind of" relationships amongst nouns; those things you listed are verbs. Those should be methods of a class. The class should be CharacterGenerator.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
0

CreateCharacter seems like it should not be a subclass of ClassStats but as I have no idea what's actually in any of the classes, I couldn't say for sure.

ratbum
  • 1,030
  • 12
  • 29
  • ClassStats are the way that a characters Strength, Toughness, Intelligence, and Wits should be manipulated. Depending on what class they choose the stats change accordingly. – user1056607 Nov 29 '11 at 01:07
  • I'd have just had CharacterClass as the superclass. Then I'd have Warrior or Mage or whatever inheriting from that. You should not need CreateCharacter. That should be in the CharacterClass constructor. – ratbum Nov 29 '11 at 01:09
0

From what I see, you're not going backwards. Inheritance gets more specific - e.g. Apple inherits from Fruit (which implements IEdible!) which inherits Object. Not the other way around. Of course, it's not completely evident in which direction your classes flow, so I'm not sure. Just make sure the base class is least specific and derived classes are more specific than the base classes. A sign that you're doing it the wrong way is if you're often shadowing methods using private new xxx MyFunction() { //....

Ry-
  • 218,210
  • 55
  • 464
  • 476
  • GenerateStats creates the basic strength, toughness, wit, and intelligence of the particular character. ClassStats detail how to change those stats around, a warrior is stronger than a mage. Finally CreateCharacter actually makes the character, name, stats, and eventually the rest of the items a character will have. – user1056607 Nov 29 '11 at 01:06
  • @user1056607: Those are much better off being functions, then... object-oriented programming doesn't mean everything has to be a class. – Ry- Nov 29 '11 at 01:08
  • Is it resource consuming to have classes over functions? – user1056607 Nov 29 '11 at 01:15
  • @user1056607: Probably. It's not a matter of that, though - you just *don't* use classes for that. It's semantics. – Ry- Nov 29 '11 at 01:20
  • @user1056607, it can be human-resource-consuming if it makes things harder to understand and human resources are usually more expensive than CPU cycles. – Dan Bryant Nov 29 '11 at 01:28
0

Rephrasing (as Eric has pointed out, using verbs is misleading), I believe your question is:

Should a CharacterGenerator be a kind of ClassGenerator which should itself be a kind of StatsGenerator? A few considerations:

  1. Do you have other types of things that you would expect to derive from ClassGenerator or StatsGenerator? If not, you don't need inheritance.

  2. Do you have other code that wants to be able to use any StatsGenerator or any ClassGenerator? If you don't have code that operates using the base classes, you don't need base classes.

Based on the names, I'm thinking what you're really trying to describe is a composition relationship. See if this expression sounds more like what you're trying to do:

You have a CharacterGenerator, which uses a ClassGenerator to generate the character class and a StatsGenerator to generate the character stats. The result is a Character containing a Class and Stats.

There are lots of ways to model and solve problems when programming; it's best to prefer the simplest approach and inheritance relationships add complexity. You should have a good reason for introducing that complexity if you plan to use it.

Also, as others have pointed out, you don't necessarily need to define a class to composite behavior. In some cases, a method or a few methods is sufficient. That said, it's not necessarily bad to err on the side of 'too small' (small classes with few methods) rather than 'too big' (a few giant classes full of all sorts of different methods.) Finding the right balance is tricky, so experiment.

Dan Bryant
  • 27,329
  • 4
  • 56
  • 102
  • Thank you for the ideas to consider. I am considering reusing the StatsGenerator for the Monsters I will be putting in the game. When I include monsters, that hierarchy path will look like: GenerateStats -> MonsterRace -> GenerateMonster. MonsteRace will be what kind of monster it is, and GenerateMonster will be for particular monsters. – user1056607 Nov 29 '11 at 01:13