Question

I am trying to really get a good idea how to think in OOP terms, so I have a semi-hypothetical scenario in my mind and I was looking for some thoughts.

If I wanted to design a simulation for different types of people interacting with each other, each of whom could acquire different proficiency levels in different “skills”, what would be an optimal way to do this?

It’s really the “skills” thing that I was a bit caught up on. My requirements are as follows:

-Each person either “has” a skill or does not

-If people have skills, they also have a “proficiency level” associated with the skill

-I need a way to find and pick out every person that has certain skills at all, or at a certain level
-The design needs to be extendible (ie, I need to be able to add more “skills” later)

I considered the following options:

1. have a giant enum for every single skill I include, and have the person class contain an
   “int Skills[TOTAL_NUM_SKILLS]” member. The array would have zeros for “unacquired” skills, and 1 to (max) for proficiency levels of “acquired skills”.

2. have the same giant enumeration, and have the person class contain a map of skills (from the enum) and numbers associated with the skills so that you can just add only the acquired skills to the map and associate a number this way.

3. Create a concrete class for every single skill, and have each inherit from an abstract base class (ISkill, say), and have the person class have a map of ISkill’s

Really, option 1 seems like the straightforward no-nonsense way to do it. Please criticize; is there some reason this is not acceptable? Is there a more object oriented way to do this?

I know that option 3 doesn’t make much sense right now, but if I decided to extend this later to have skills be more than just things with proficiency associated with them (ie, actually associate new actions with the skills (ISkill::DoAction, etc), does this make sense as an option?

Sorry for the broad question, I just want to see if this line of thought makes sense, or if I’m barking up the wrong tree altogether.

Answer 1

The problem with option 1 is future compatibility. Say you were shipping this framework to customers. Now, the customer has built this array of Skill values, which is length TOTAL_NUM_SKILLS, for each person. But this fails as soon as you try to add another skill, and especially as you try to reorder skills.

What if the customer is using an RPC framework in which a client and server pass Person objects over the wire? Now, unless the customer upgrades the client and server at the exact same time, the RPC calls break, since now the client and server expect arrays of different lengths. This can be particularly tricky because the customer may own only the client, or only the server, and be unable to upgrade both at once.

But it gets worse. Say the client has written out a Person object to disk in some file. If they decided to serialize a person as a simple list of numbers, then a new skill will cause the deserialization code to fail. Worse, if you reorder skills in your enum, the deserialization code may work just fine but give a wrong answer.

I like option 3 exactly for the reason you named: later you can add more functionality, and do so safely (well, except for the fact that every public change is a breaking change if your customers exercised certain edge cases in the language).