Which is better: a bunch of getters or 1 method with a selection string parameter?

Question

Our knowledge domain involves people walking over a pressure-recording plate with their bare feet. We do image recognition which results in objects of the 'Foot' class, if a human foot is recognized in the sensor data.

There are several calculations that must be performed on the foot's data.

Now, which API would be better:

class Foot : public RecognizedObject  { 
  MaxPressureFrame getMaxPressureFrame();
  FootAxis getFootAxis();
  AnatomicalZones getAnatomicalZones();

  // + similar getters for other calculations

  // ...
}

Or:

class Foot : public RecognizedObject {
  virtual CalculationBase getCalculation(QString aName);

  // ...
}

Now, there are a lot of pro's and con's I can come up with, but I can't really decide which are the most important. Note, this is an end-user application, not a software library we sell.

Any advice?

Some pro's for the first approach could be:

• KISS - everything is very concrete. The API, but the implementation as well.
• strongly typed return values.
• inheriting from this class is fool-proof. Nothing can be overridden, only added.
• API is very closed, nothing goes in, nothing can be overridden, so less can go wrong.

Some con's:

• The number of getters will grow, as every new calculation we invent gets added to the list
• API is more likely to change, and if breaking changes are introduced, we need a new API version, a Foot2.
• in case of re-use of the class in other projects, we might not need every calculation

Some pro's for the second approach:

• more flexible
• the api is less likely to change, (assuming we got the abstraction correct, if not, changing will cost more)

Some con's:

• loosely typed. Needs casts on every call.
• the string parameter - I have bad feelings about that (branching on string values...)
• There is no current use case/requirement that mandates the extra flexibility, but there might be in the future.
• the API imposes restrictions: every calculation needs to derive from a base class. Getting a calculation will be forced through this 1 method, and passing extra parameters will be impossible, unless we devise an even more dynamic, super-flexible way of passing parameters which increases complexity even more.

Answer 1

I think in first approach will pay off. Magic strings can create the following issues: Typing errors, misuse, non-trivial return type safety, lack of code completion, unclear code (did this version have that feature? i guess we'll find out at runtime). Using enums will resolve some of those issues, but let's look at the cons you raised:

• The number of getters will grow, as every new calculation we invent gets added to the list

True, that can be annoying, however it keeps things nice and strict, and gives you code completion anywhere in your project in any modern IDE, with good heading comments that is much more useful than enums.

• API is more likely to change, and if breaking changes are introduced, we need a new API version, a Foot2.

True, but that's actually a huge pro ;) you can define interfaces for partial APIs, and then you don't need to re-compile dependent class that are not affected by newer APIs (So no need for Foot2). That allows for better decoupling, the dependency is now of the interface and not the implementation. Moreover if an existing interface changes, you will have a compilation error in dependent classes, which is great to prevent stale code.

• in case of re-use of the class in other projects, we might not need every calculation

I don't see how using magic strings or enums will help with that... If I understand correctly, either you include the code in the Foot class or you break it down to a few smaller classes, and that goes for both options

Answer 2

I would recommend option 3: Make it clear that the calculations are not an intrinsic part of the abstraction of a Foot, but operate on it. Then you can split Foot and the calculations into separate classes, like this:

class Foot : public RecognizedObject {
public:
    // Rather low-level API to access all characteristics that might be needed by a calculation
};

class MaxPressureFrame {
public:
    MaxPressureFrame(const Foot& aFoot); // Performs the calculation based on the information in aFoot
    //API for accessing the results of the calculation
};

// Similar classes for other calculations

This way, you still have strong typing of your calculation, and you can add new ones without affecting existing code (unless you made a serious error in the amount information exposed by Foot).