6

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Names#Function_Names

常规函数大小写混合；访问器和修改器匹配变量的名称：MyExcitingFunction()、MyExcitingMethod()、my_exciting_member_variable()、set_my_exciting_member_variable()。

对用户隐藏实现细节不是封装的全部意义，因此他/她不知道访问器/突变器方法是否返回/修改成员变量？如果我更改变量名称或更改它在对象中的存储方式怎么办？

编辑：

如果我有一个实例变量int foo_，它看起来很简单

int foo() const { return foo_; }

但是如果我添加另一个返回的方法，foo_ + 2我应该命名 ifbar还是GetBar？

int bar() const { return foo_ + 2; }
int GetBar() const { return foo_ + 2; }

如果我选择GetBar并稍后决定将返回值缓存在另一个成员变量bar_中，我是否必须将方法重命名为bar？

4

4 回答 4

5

实际上，封装的意义在于隐藏一个类的内部工作，而不一定是隐藏事物的名称。成员变量的名称无关紧要；这是访问器或修改器提供 的间接级别。

拥有访问器使您能够更改类的内部工作方式（包括成员变量的名称），而不会破坏类与外部世界的接口。类的用户不必关心实现细节，包括在类内部命名什么，而只关心从外部看到的类的行为。

换句话说，类的用户不应该依赖 Google 的样式指南来确定他们是否正在修改成员变量。

于 2013-02-05T16:41:50.720 回答
5

因为谷歌风格指南仅供谷歌员工遵循。相反 - 它不是一个很好的风格指南。

举个例子——他们明确禁止通过非常量引用传递，因为它可能会“令人困惑”。

所以你是对的，它违背了封装的目的。不要用它来引导自己。

于 2013-02-05T16:40:18.967 回答
2

在考虑一个类时，它可能在概念上具有可见状态，可以由客户端访问。这种状态如何在类中表示是另一回事，这就是访问器（getter 和 setter）隐藏的内容。我自己的命名约定也做出了这种区分：如果函数在概念上是 getter 或 setter，它具有属性的名称，通常是名词；否则，它是一个动词。我区分了函数获取或设置在概念上不是类的一部分的情况（例如，部分取决于参数）、具有动词get或set名称的情况，以及函数实际修改的情况什么是概念上的属性，在这种情况下它们不是。

其余的，就像大多数风格指南一样，并不是每个人都完全同意这个。例如，我不确定我是否喜欢他们的命名约定。它们被称为命名约定，因为它们就是：任意约定。唯一真正的硬性规则是必须区分类型、宏和其他内容，并且名称不应以下划线开头或结尾。（还有一些更软的规则：我会非常怀疑最终使局部变量的名称比全局变量的名称更长的约定。）

于 2013-02-05T17:16:56.190 回答
1

我可能对常识的假设太过分了，但我很确定保留已发布的界面优先于遵循命名指南。

由于您的原始bar/GetBar函数不是访问器，我认为它应该遵循常规名称指南并被调用GetBar。

如果您稍后引入bar_，以便在某种意义上该函数成为访问器，我很确定您不应该删除GetBar. 我想您也可以添加一个函数bar()，定义为执行相同的操作，但我认为我不会将样式指南解释为要求这样做。

我也很确定，一旦您发布的接口包含您（和调用者）认为是“访问器”的函数，封装无论如何在某种程度上都是窗外的，因为您正在谈论的状态对象而不是其行为。仅仅因为函数在当前实现中返回成员变量的值并不意味着它必须被记录为访问器。但是，如果您坚持编写公开认可为访问器的函数，Google 会告诉您如何命名它们。典型的例子是，一个足够笨的数据记录对象可能有合理的访问器，因为整个类被公开定义为一组可能有一点行为的字段。

我之前已经读过几次该风格指南，但我从未在 Google 工作过，所以我不知道他们的代码审查如何在实践中应用它。我应该认为，一个如此规模的组织不可能在每个细节上都完全一致。所以你的猜测可能和我的一样好。

于 2013-02-05T17:14:56.470 回答