公共数据成员与getter、setter

两者都不。你应该有做事情的方法。如果这些事情中的一个恰好对应于一个特定的内部变量,那就太好了,但是不应该有任何东西将这一点传达给类的用户。

私有数据是私有的,因此您可以随时替换实现(并且可以进行完全重建,但这是另一个问题)。一旦你把精灵从瓶子里放出来,你会发现不可能再把它插回去。

编辑:根据我对另一个答案的评论。

我的意思是你问错了问题。在使用getter/setter或拥有公共成员方面没有最佳实践。只有对你的特定对象最好的东西,以及它是如何建模一些特定的真实世界的东西(或者在游戏中想象的东西)。

就个人而言,两害相权取其轻。因为一旦您开始创建getter/setter,人们就不再设计对象,而是关注哪些数据应该可见,哪些数据不应该可见。对于公众来说,情况更糟,因为人们倾向于把所有的事情都公之于众。

相反,检查对象做了什么,以及它对于某个对象意味着什么。然后创建为该对象提供自然接口的方法。自然接口涉及到使用getter和setter公开一些内部属性,就这样吧。但重要的是,您提前考虑了它,并出于设计上的原因创建了getter/setter。

不,这根本不是一回事。

通过对类接口的不同方法可以实现不同级别的保护/实现隐藏:

1。公共数据成员:

• 提供对数据成员的读写(如果不是常量)访问
• 公开数据对象在物理上存在并且在物理上是该类的成员的事实(允许创建指向该数据成员的成员类型指针的指针)
• 提供对数据成员的左值访问(允许创建指向该成员的普通指针)

2。返回对数据块(可能是对私有数据成员)的引用的方法:

• 提供对数据的读写(如果不是常量)访问
• 显示数据对象实际存在但 不暴露 它在物理上是此类的成员(不允许创建指向数据的成员类型指针的指针)
• 提供对数据的左值访问(允许创建指向数据的普通指针)

三。getter和/或setter方法(可能访问私有数据成员):

• 提供对属性的读和/或写访问
• 不暴露 数据对象在物理上存在的事实,更不用说物理上存在于此类中(不允许创建指向该数据的成员类型指针的指针,或任何类型的指针)。
• 不提供 对数据的左值访问(不允许创建指向它的普通指针)

getter/setter方法甚至不公开属性由物理对象实现的事实。也就是说,getter/setter对后面可能没有物理数据成员。

考虑到上述因素,很奇怪有人声称getter和setter对与公共数据成员相同。事实上,他们没有共同点。

当然,每种方法都有不同之处。例如,getter方法可能返回对数据的常量引用,该引用将把数据放在(2)和(3)之间。

如果每个数据项都有getter和setter,那么将数据设为私有没有意义。这就是为什么每个数据项都有getter和setter是个坏主意。考虑std::string类——它(可能)有一个getter、size()函数,根本没有setter。

或考虑 BankAccount 目标-我们应该 SetBalance() 设置更改当前余额?不,大多数银行都不会感谢你实施了这样一项措施。相反,我们想要 ApplyTransaction( Transaction & tx ) .

getter和setter允许您将逻辑应用于来自私有成员的输入/输出,从而控制对数据的访问(封装到那些知道OO术语的用户)。

公共变量使类的数据对公众开放,以便进行不受控制和未经验证的操作,这几乎总是不可取的。

你也必须长期考虑这些事情。您现在可能没有验证(这就是为什么公共变量似乎是一个好主意),但有可能它们会被添加到后面。提前添加它们会离开框架,因此减少对RAOD的重新分解,更不用说验证不会以这种方式破坏依赖代码)。

不过,请记住,这并不意味着每个私有变量都需要自己的getter/setter。尼尔在他银行业的例子中提出了一个很好的观点,那就是有时getter/setter是没有意义的。

公开数据。在某一天你确实需要“getter”或“setter”中的逻辑的情况下(不太可能),你可以将数据类型更改为一个重载代理类。 operator= 和/或 operator T (其中t=您现在使用的任何类型)来实现必要的逻辑。

编辑:控制对数据的访问构成封装的想法基本上是错误的。封装是为了隐藏实现的细节(通常!) 不 控制对数据的访问。

封装是抽象的补充:抽象处理对象的外部可见行为,而封装处理隐藏如何实现该行为的细节。

实际使用getter或setter 减少 抽象级别和公开实现——它要求客户机代码意识到这个特定的类将逻辑上的“数据”实现为一对函数(getter和setter)。按照我上面的建议,使用代理提供了 真实的 封装——除了一个模糊的角盒,它完全 兽皮 逻辑上的一段数据实际上是通过一对函数实现的。

当然,这需要保持在上下文中:对于某些类,“数据”根本不是一个好的抽象。一般来说,如果你能提供更高的水平 操作 而不是数据,这更可取。尽管如此,对于某些类,最有用的抽象是读写数据——如果是这样的话,(抽象的)数据应该像其他数据一样可见。获取或设置该值可能涉及的不仅仅是简单的位复制,这是一个应该对用户隐藏的实现细节。

如果您非常确定您的逻辑很简单,并且在读/写变量时不需要做其他事情,那么最好保持数据公开。在C++案例中,我更喜欢使用Struts而不是类来强调数据是公共的事实。

然而,在访问数据成员时,您通常需要做一些其他的事情,或者您希望稍后给自己自由添加这个逻辑。在这种情况下,getter和setter是个好主意。您的更改对代码的客户端是透明的。

附加功能的一个简单示例-您可能希望每次访问变量时都记录调试字符串。

除了封装的问题(这是足够的理由),当有getter/setter时,只要设置/访问变量,就很容易设置断点。

使用公共字段而不是getter和setter的原因包括:

1. 没有非法值。
2. 需要客户端对其进行编辑。
3. 能够写一些东西,比如object.x.y=z。
4. 作出一个强有力的承诺,即价值只是一个价值,没有任何副作用与之相关(也不会在未来)。

根据您所使用的软件类型的不同,这些都可能是非常特殊的情况(如果您认为您遇到了一个可能是错误的),或者它们可能会一直发生。这要看情况而定。

(从 Ten Questions on Value-Based Programming )

在严格的实践基础上,我建议您从将所有数据成员保密开始, 和 让他们的getter和setter私有化。当您发现世界其他地方(即您的“(l)用户社区”)实际需要什么时,您可以公开适当的getter和/或setter,或者编写适当控制的公共访问器。

另外(为了Neil的利益),在调试期间,有时在读取或写入特定数据成员时,有一个方便的位置来挂起调试打印和其他操作是很有用的。有了getter和setter,这很容易。对于公共数据成员来说,这是一个巨大的痛苦。

我一直认为getter和setter在大多数编程语言中都是刻意冗长的,特别是为了让你三思而后行——为什么调用者需要知道你的类的内部工作应该是你头脑中的问题。

我相信简单地使用getter和setter来获取和设置值是没有用的。公共成员和私有成员使用这种方法没有区别。只有当您需要以某种方式控制这些值,或者当您认为将来这些值可能有用时(添加一些逻辑不会使您编辑其余代码),才使用getter和setter。

As a reference, read C++ guidelines (C.131)

我建议您没有公共数据成员(pod结构除外)。我也不建议您为所有数据成员设置getter和setter。相反,为类定义一个干净的公共接口。这可能包括获取和/或设置属性值的方法,并且这些属性可以作为成员变量实现。但不要为所有成员制作getter和setter。

其思想是将接口与实现分离,允许您修改实现,而类的用户不必更改其代码。如果通过getter和setter公开所有内容,那么与使用公共数据相比,没有任何改进。

使用getter和setter可以修改为用户提供值的方式。

考虑以下事项:

double premium;
double tax;

然后你用这个在整个地方写代码 premium 获得保费的价值:

double myPremium = class.premium;

您的规格刚刚改变,从用户的角度来看,溢价需要 premium + tax

你必须在任何地方修改 溢价 值正在您的代码中使用,并添加 tax 对它。

如果相反,您是这样实现的:

double premium;
double tax;

double GetPremium(){return premium;};

所有代码都将使用 GetPremium() 你的 税 更改为一行:

double premium;
double tax;

double GetPremium(){return premium + tax;};

返回值还影响getter和setter的使用。获取变量的值或访问私有数据成员变量是不同的。按值保持完整性,按引用或按指针保持不太完整。

getter和setter的存在主要是为了控制成员的获取方式和设置方式。getter和setter不只是作为访问特定成员的一种方式存在,但是为了确保在我们尝试设置成员之前,它可能满足某些条件,或者如果我们获取它,我们可以控制在非基元类型的情况下返回该成员的副本。总的来说,当您希望管道传输数据成员如何与之交互时,应该尝试使用g/s'ers,如果没有它们,将导致成员以一种特殊的方式使用。