Different scoring algorithms for different competition elements

Question

I am creating a scoring system for a competition that is somewhat obscure, but it resembles the Olympics in terms of its high-level structure. Therefore, I will ask my question in terms of an abstracted, fictional version of the Olympics, since everyone can relate to that to some degree.

Assume the following hierarchy of classes and score rollups:

• Event class has one or more Sports (e.g., the 2012 Olympics has Decathlon, IndividualMedley, etc.) and one or more EventScores (one EventScore per Team per Event calculated by adding up the team's SportScores for a particular Event)
• Sport class has one or more Elements (e.g., Decathlon has Shotput, Javelin, etc.) and one or more SportScores (one SportScore per Team per Sport calculated by adding up the team's ElementScores for a particular Sport)
• Element class has one or more Rounds (e.g., Shotput has Throw1, Throw2, etc.) and one or more ElementScores (one ElementScore per Team per Element calculated by adding up the team's RoundScores for a particular Element)

The scoring algorithm (let's call it the CalculateRoundScore() method) of a particular RoundScore depends on the Element to which the Round belongs. Examples:

• Shotput element: CalculateRoundScore(double ThrowDuration, double ThrowDistance, double GruntVolume) { algorithm; }
• Javelin element: CalculateRoundScore(double ThrowDuration, double ThrowDistance, double GruntVolume) { algorithm (different from Shotput algorithm even though parameters are the same, which would seem to eliminate overloading as a viable option); }
• 100MeterDash element: CalculateRoundScore(double Time, bool FalseStart) { algorithm; }

Although I am seeking general architecture guidance, here are some of my specific questions:

• How do I associate different CalculateRoundScore methods to different Elements?
• Should I use interfaces, inheritance, overloading, or some other approach?
• In which class(es) should the various CalculateRoundScore methods be located?

Conceptually, I can imagine each Element being an ICalculateRoundScore interface. However, that only makes sense if I create a different class for each different element, which doesn't seem right. It feels like I need some kind of a lookup in which the Round class picks its particular CalculateRoundScore method depending on the Element to which it belongs, but I'm not sure what would be the correct object-oriented way to do this.

Answer 1

However, that only makes sense if I create a different class for each different element, which doesn't seem right

To me, this feels perfectly right, since, it is just an application of the classic "strategy" pattern (in this case a RoundScoreCalculationStrategy). I would design this in a way like this:

 interface RoundScoreCalculationStrategy
 {
     double Calculcate(Measurements m);
 }

Strategy objects can easily be put into any kind of lookup table. Measurements will be a base type (or interface) for encapsulating the possible results of one round in one of your sport events (like the tuple ThrowDuration, ThrowDistance, GruntVolume) - so you can separate the supply of those values from the score calculation. You still have to construct different Measurement objects with different constructor parameters, but now you can

• construct those objects at the place in code where you "run the round" (which can be a completely different place from where the scoring takes place)
• reuse the same Measurement objects if they contain the same parameter tuples (for example, for Shotput and Javelin), even if the scoring calculation is a different one

Of course, you may consider to use delegate functions instead of different RoundScoreCalculationStrategy objects (which may result in less code if each of your score calculation algorithms is just a small function), but the main idea keeps the same.

One thing to add: maybe it is sufficient not to distinguish between the Strategy classes and the "Element" classes at all. Your different disciplines (which you called Elements above) could get a common virtual base class Discipline - (could be also an interface), where CalculateScore(Measurements m) is just a virtual method of that base class, and Shotput, Javelin etc. are subclasses of Discipline with different implementations of that method.