C ++在使用类时,为什么要使用get和set函数?

时间:2013-06-06 17:06:46

标签: c++ class

我被告知不要在课堂上公开我的变量。我应该总是做一个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 ++编程风格吗?

7 个答案:

答案 0 :(得分:4)

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

假设有一天您想要更改这些变量的名称,或者您想要更改类的实现,以便成员变量的类型和数量与当前变量不同:将受影响的函数数量通过这种变化?你需要重写几个函数(至少部分)?

对,可能是无限的。你无法统计他们。另一方面,如果你有getter和setter,那么只有这4个函数可以访问你的类的内部表示。更改内部表示不需要更改客户端功能的代码;只有那4个成员函数可能需要更改。

通常,封装使您的未来变化更加轻松。在某个特定时间点,您可能希望每次设置某个属性时都记录消息。您可能希望每次设置某个属性时触发事件。您可能希望动态计算某个值,而不是每次从缓存数据成员读取它,或者从数据库中读取它,或者其他任何值。

使用getter和setter可以实现任何这些更改,而无需更改客户端代码。

答案 1 :(得分:1)

您可以将明确的getter和setter编写为未来开发的理智计划。如果你的班级'用户直接访问其成员,您需要以与该习惯不兼容的方式更改类,您必须以这种方式更改与您接口的每一块代码。如果你编写一个getter和setter,编译器会将它优化为与直接访问相当的时间(如果就是这样),你可以在以后更改逻辑 - 无需更改大量其他代码

答案 2 :(得分:1)

就一般设计理念而言,在实施访问者方面没有“永远”或“从不”,而没有实现整个社群同意的访问者。

许多人会建议您制作所有数据成员private并提供访问权限&存取器。总是

如果不希望从客户端代码更改数据成员,则其他人会告诉您创建数据成员private,否则将public留下。{/ p>

然而其他人会告诉你,类根本不应该有多个数据成员,所有数据都应该封装在另一个对象中,最好是struct

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

如果你问我,我的首选是public,直到我有理由不这样做。简单。但那只是我。

答案 3 :(得分:0)

数据封装是OOP的主要原则之一。它是将数据和函数组合成一个称为类的单元的过程。使用封装方法,程序员无法直接访问数据。数据只能通过类中存在的函数访问,以便隐藏用户的类的实现细节。这是为了保护调用者和函数不会意外地改变方法的行为,或者需要知道方法是如何工作的。

答案 4 :(得分:0)

我从第一个OOP类中回忆起的教科书回答是:Get和set方法用于包装私有变量。通常人们在获取和设置之间进行比较,或者只是将这些变量设置为公开;在这种情况下,get和set方法很好,因为它可以防止那些变量因错误等而被意外修改。

人们(我参加那个班级的时候)可能会问“没有得到并设置也会修改这些变量,如果是这样,那么与被修改为公共变量有什么不同”。

基本原理是:要获取和设置函数,您要求用户或您自己明确指定他们想要通过调用这些函数来修改变量。如果不调用这些函数,私有变量将不太可能或不经意地修改(仍然可能取决于实现)。

答案 5 :(得分:0)

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

这是吸气剂和制定者的主要原因,即使它们非常简单,最好还是拥有它。你会感谢自己一次。

答案 6 :(得分:0)

简而言之,你不应该这样做。

一般来说,我建议阅读Fowler的重构,然后你会看到一张图片,这些图片会因裸露的数据而受到阻碍,以及什么样的访问能够很好地对齐。而且重要的是整个事情是否适用于你的案件。

正如你所知道的那样,你可以放心地忽略“应该做/不做”这样的事情,就像在这个答案的开头或其他人那样。