0

我被告知不要在课堂上公开我的变量。我应该总是做一个 get 和一个 set 函数。例如 ：

class Whatever
{

public:
  void setSentence(const std::string &str) { sentence = str; }
  void setAnInteger(const int integer) { anInteger = integer; }

  std::string getSentence() { return sentence; }
  int getAnInteger() { return anInteger; }

private:
  std::string sentence;
  int anInteger;

};

我为什么要那么做？只是简单地使用这些变量不是更方便吗？另外，这是一种好的 c++ 编程风格吗？

4

7 回答 7

5

主要原因是增加封装。如果您的类公开了这些成员变量，则客户端代码中的许多函数将依赖于这些变量。

假设有一天您想要更改这些变量的名称，或者您想要更改类的实现，以便成员变量的类型和数量与当前不同：有多少函数会受到此更改的影响? 你需要重写多少个函数（至少部分重写）？

对，可能是无限的。你不能把它们都数一遍。另一方面，如果你有 getter 和 setter，那么只有这 4 个函数可以访问你的类的内部表示。更改内部表示不需要对客户端函数的代码进行任何更改；只有这 4 个成员函数可能需要更改。

一般来说，封装使您的生活更轻松，以应对未来的变化。在某个时间点，您可能希望在每次设置某个属性时记录一条消息。您可能希望在每次设置某个属性时触发一个事件。您可能希望即时计算某个值，而不是每次都从缓存数据成员中读取它，或者从数据库中读取它，或其他任何东西。

拥有 getter 和 setter 允许您实现任何这些更改，而无需更改客户端代码。

于 2013-06-06T17:16:26.857 回答
2

就一般设计理念而言，在实现访问器与不实现整个社区一致同意的访问器时，没有“总是”或“从不”。

许多人会建议您创建所有数据成员private并提供访问器和修改器。总是。

private如果不希望从客户端代码更改数据成员，其他人会告诉您创建数据成员，public否则保留它们。

还有一些人会告诉你，类根本不应该有一个或多个数据成员，所有数据都应该封装在另一个对象中，最好是一个struct.

您必须自己决定哪个是正确的，请记住，这不仅取决于您的方法，还取决于您所在组织的方法。

如果你问我，我的偏好是做所有事情public，直到我有理由不做。简单的。但这只是我。

于 2013-06-06T17:15:27.740 回答
1

您编写明确的 getter 和 setter 作为未来发展的明智计划。如果您的类的用户直接访问其成员，并且您需要以与该习惯不兼容的方式更改类，则必须更改以这种方式与您交互的每一块代码。如果您编写 getter 和 setter，编译器会将其优化为与直接访问时间等效（如果仅此而已），您可以稍后根据需要更改逻辑 - 无需更改大量其他代码.

于 2013-06-06T17:15:12.693 回答
0

数据封装是OOP的主要原则之一。它是将数据和函数组合成一个称为类的单元的过程。使用封装的方法，程序员不能直接访问数据。数据只能通过类中存在的函数访问，因此类的实现细节对用户是隐藏的。这是为了保护调用者和函数免于意外更改方法的行为，或者避免需要知道方法的工作原理。

于 2013-06-06T17:11:36.567 回答
0

从我上第一堂 OOP 课时回忆起的教科书式答案是：Get 和 set 方法用于包装私有变量。通常人们会比较 get 和 set 或者只是将这些变量设置为 public；在这种情况下，获取和设置方法很好，因为它可以保护这些变量不因错误等而被意外修改。

人们（我上那门课时的我）可能会问“不是 get 和 set 也修改这些变量，如果是，那与被修改为公共变量有什么不同”。

基本原理是：要拥有 get 和 set 功能，您是在要求用户或您自己明确指定他们要通过调用这些函数来修改变量。如果不调用这些函数，私有变量将不太可能（仍然可能取决于实现）被不情愿或意外地修改。

于 2013-06-06T17:15:54.290 回答
0

当您使用 get 或 set 方法并在代码中使用它 40 次时，您可以更轻松地处理未来的更改。想象一下，您使用公共变量并在代码中使用它 40 次。在开发程序一个月后，你会想出一个好主意：如果我将这个变量除以 1000 会怎样，这样我就有更好的值来计算！哇，太好了，但现在我必须找到每一行，在哪里使用并更改它。如果我只有一个 get 方法:(

这就是 getter 和 setter 的主要原因，即使它们很简单，最好有它。你会感谢自己一次。

于 2013-06-06T17:16:18.817 回答
0

简而言之，你不应该那样做。

一般来说，我建议阅读 Fowler 的 Refactoring，然后您将了解裸数据会阻碍什么，以及哪种访问方式可以很好地对齐。重要的是，整件事是否适用于您的案件。

正如您所知道的利弊，您可以放心地忽略“应该做/不应该”的事情，比如在这个答案的开头或其他人。

于 2013-06-06T17:17:04.113 回答