哪个更好：一堆吸气剂或带有选择字符串参数的1个方法？

我们的知识领域涉及人们赤脚行走在压力记录板上。如果在传感器数据中识别出人脚，我们会进行图像识别，从而产生“脚”类对象。

必须对脚的数据执行一些计算。

现在，哪种API更好：

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

  // + similar getters for other calculations

  // ...
}

要么：

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

  // ...
}

现在，我可以提出很多优点和缺点，但是我不能真正决定哪个最重要。请注意，这是最终用户应用程序，而不是我们出售的软件库。

有什么建议吗？

第一种方法的一些专家可能是：

• 吻-一切都非常具体。API，但实施也是如此。
• 强类型返回值。
• 从此类继承是万无一失的。什么都不能覆盖，只能添加。
• API是非常封闭的，什么都不会进入，什么都不能被覆盖，所以更少的地方会出错。

一些缺点：

• 随着我们发明的每一项新计算都被添加到列表中，吸气剂的数量将会增加
• API更可能会更改，如果引入了重大更改，我们需要一个新的API版本，即Foot2。
• 如果在其他项目中重复使用该类，我们可能不需要进行所有计算

第二种方法有些专业人士：

• 更灵活
• api更改的可能性较小，（假设我们正确提取了抽象，如果不正确，更改将花费更多）

一些缺点：

• 松散类型。每次通话都需要转换。
• 字符串参数-我对此有不好的感觉（分支字符串值...）
• 当前没有用例/需求要求额外的灵活性，但将来可能会存在。
• API施加了限制：每次计算都需要从基类派生。除非通过一种更动态，更灵活的方式来传递参数，否则将无法通过这种1方法来进行计算，而且传递额外的参数将是不可能的，这将进一步增加复杂性。

我认为第一种方法会有所收获。魔术字符串可能会产生以下问题：键入错误，滥用，返回类型的安全性不佳，代码完成不足，代码不清晰（此版本具有该功能吗？我想我们会在运行时找到）。使用枚举可以解决其中的一些问题，但让我们看一下您提出的缺点：

• 随着我们发明的每一项新计算都被添加到列表中，吸气剂的数量将会增加

没错，这可能很烦人，但是它使事情变得更加严格和严格，并且可以在任何现代IDE中的项目中的任何地方为您提供代码完成功能，并且标题注释比枚举要有用得多。

• API更可能会更改，如果引入了重大更改，我们需要一个新的API版本，即Foot2。

是的，但这实际上是一个强大的专业;），您可以为部分API定义接口，然后无需重新编译不受较新API影响的依赖类（因此不需要Foot2）。这样可以实现更好的去耦，依赖关系现在是接口而不是实现。此外，如果现有接口发生更改，则在依赖类中将出现编译错误，这对于防止代码过时很有用。

• 如果在其他项目中重复使用该类，我们可能不需要进行所有计算

我看不出使用魔术字符串或枚举将如何帮助您...如果我正确理解，您可以将代码包含在Foot类中，或者将其分解为几个较小的类，这两种选择都适用

我会建议选择3：明确说明计算不是a的抽象的固有部分Foot，而是对其进行运算。然后，您可以将Foot计算拆分为单独的类，如下所示：

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

这样，您仍然可以对计算进行强类型输入，并且可以在不影响现有代码的情况下添加新的计算（除非您在公开的数量信息上犯了严重错误Foot）。