在接口中使用 const 是否有意义？

Question

我有一个执行一些计算的模块，并在计算过程中与其他模块进行通信。由于计算模块不想依赖其他模块，所以它暴露了一个这样的接口（当然这是一个非常简化的版本）：

class ICalculationManager
   {
   public:
      double getValue (size_t index) = 0;
      void setValue (size_t index, double value) = 0;
      void notify (const char *message) = 0;
   };

想要使用计算模块的应用程序需要编写自己的接口实现，并且将其提供给计算工具，如下所示：

MyCalculationManager calcMgr;
CalculationTool calcTool (calcMgr);
calcTool.calculate();

我现在想知道将“const”添加到 ICalculationManager 接口的方法中是否有意义。

getValue 方法只获取某些内容而不改变任何内容似乎是合乎逻辑的，因此我可以将此设置为 const。 setValue 可能会更改数据，因此不会是 const。 但对于像通知这样更通用的方法我不能确定。

事实上，对于任何方法，我现在都不能确定该方法确实是作为 const 方法实现的，如果我将接口方法设置为 const，我也会强制所有实现都为 const，这可能是不希望的。

在我看来，只有当您事先知道您的实现是什么以及它是否是 const 时，const 方法才有意义。这是真的吗？

将这种接口的方法设置为 const 没有意义吗？如果它有意义，那么确定该方法是否应该是 const 的好规则是什么，即使我不知道实现是什么？

编辑：将通知参数从“char *”更改为“const char *”，因为这会导致不相关的答案。

Answer 1

当您向客户端宣传调用该函数永远不会更改对象的外部可见状态时，您可以创建一个函数const。您的对象只有一项可以检索的状态，即 getValue。

因此，如果 getValue 可以导致下一个 getValue 返回不同的值，那么当然，将其保留为非常量。如果您想告诉客户端调用 getValue() 永远不会更改下一个 getValue() 返回的值，那么请将其设置为 const。

与notify相同：

double d1 = mgr->getValue(i);
mgr->notify("SNTH");  // I'm cheating.
double d2 = mgr->getValue(i);
assert(d1==d2);

如果这对于所有情况和所有i都适用，那么notify()应该是const。否则不应该。

Answer 2

是的。无论何时何地，只要合理，就应该使用 const。执行计算的方法（这是您的界面所建议的）应该改变它的可观察行为是没有意义的，因为它调用了“notify”。 （就此而言，通知与计算有何关系？）

我将接口成员之一设为 const，您不会强制客户端成为 const --您只需允许他们使用 const ICalculationManager 即可。

我可能会制作 Notify const。如果客户端需要执行一些非常量作为通知的结果，那么Notify不是一个好的方法名称——该名称建议非状态修改转换，例如作为记录，而不是修改。

例如，大多数时候您传递接口时，您会希望使用 pass-by-reference-to-const 来传递接口实现者，但如果方法不是 const >，你不能那样做。

Answer 3

接口应该指导实现，而不是相反。如果您还没有决定某个方法或参数是否可以是 const，那么您的设计就还没有完成。

使用 const 是一种断言代码允许做什么或不允许做什么的方法。这对于推理一段代码非常有价值。例如，如果您的 notify 参数不是 const，那么它会对消息进行哪些更改？如果需要的话，如何使消息变得更大？

编辑：您似乎知道声明 const 参数的价值，所以让我们在此基础上进行构建。假设您想要一个函数来记录计算的值：

void RecordCalculation(const ICalculationManager *calculation);

您可以在该指针上调用的唯一方法是 const 方法。您可以确定，函数返回后，该对象将保持不变。这就是我对代码进行推理的意思 - 您可以绝对确定该对象不会被更改，因为如果您尝试，编译器将生成错误。

编辑 2：如果您的对象包含一些将被修改以响应逻辑常量操作（例如缓存或缓冲区）的内部状态，请继续并使用 mutable这些成员的关键字。这就是它被发明的目的。

Answer 4

对我来说，这仅取决于您的接口的合同。

对于 getter 方法，我不明白为什么它应该更改任何数据，如果发生这种情况，也许可变是一个选项。

对于 setter 方法，我同意，而不是 const 那里，因为这肯定会以某种方式改变数据。

因为如果不知道通知对您的系统意味着什么，就很难说它是什么。另外，您是否希望实现修改消息参数？如果现在的话，它也应该是 const 的。

Answer 5

无需阅读整篇文章：是的，当然，如果您想在 const 上下文中使用对象（继承 ICalculationManager），这是有意义的。一般来说，如果不操作私有数据，则应始终使用 const 限定符。

编辑：
就像 Mark Ransom 所说：你需要确切地知道你的界面功能应该如何表现，否则你的设计还没有完成。

Answer 6

我知道我会因此遭到很多反对，但在我看来，C++ 中 const 正确性的用处被过分夸大了。 const 的想法很原始（它只捕获一点概念......更改/不更改）并且成本很高，甚至包括代码重复的必要性。而且它的扩展性也不好（考虑 const_iterators）。

更重要的是，我什至不记得一个案例（甚至一个），常量正确性机制帮助我发现了一个真正的逻辑错误，那就是我试图做一些我不应该做的事情。相反，每次编译器阻止我时，const 声明部分都会出现问题（即我试图做的事情在逻辑上是合法的，但方法或参数在有关 const 性的声明中存在问题）。
在所有情况下，我都记得在哪里遇到与 const 正确性相关的编译器错误，修复方法只是添加一些缺失的 const 关键字或删除一些多余的...如果不使用 const 正确性想法，这些错误就不会出现根本就在那里。

我喜欢 C++，但当然我并不喜欢它的每一点（题外话：当我采访某人时，我经常问的一个问题是“你不喜欢<语言>的哪一部分？”..如果答案是“没有”，那么仅仅意味着我正在交谈的人仍处于粉丝阶段，并且显然没有丰富的真实经验）。

C++ 有很多部分非常好，有些部分在我看来很糟糕（例如流格式），有些部分并不糟糕，但在逻辑上既不美观也不实用。常量正确性的想法在我看来是在这个灰色地带（这不是新手的印象......我在 C++ 中进行了许多行和多年的编码后得出了这个结论）。
可能是我，但显然 const 正确性解决了我的大脑没有的问题......我还有很多其他问题，但不是当我应该更改实例状态和何时不应该更改实例状态时令人困惑的问题。

不幸的是（与流格式化不同）你不能忽略 C++ 中的常量正确性机制，因为它是核心语言的一部分，所以即使我不喜欢它，我也不得不遵守它。

你现在可能会说……好吧，但是问题的答案是什么？只是我不会对那部分语义描述太着迷……它只是一个比特，而且价格很高；如果你不确定并且可以在不声明常量的情况下逃脱，那么就不要这样做。引用或方法的常量性对编译器来说从来没有帮助（请记住，它可以合法地被抛弃），它已被添加到 C++ 中，只是作为对程序员的帮助。然而，我的经验告诉我，（考虑到高成本和低回报）这根本不是真正的帮助。