友元函数是否违反封装？ [关闭]答案

【问题标题】：Do friend functions violate encapsulation? [closed]友元函数是否违反封装？ [关闭]
【发布时间】：2019-02-13 21:31:58
【问题描述】：

friend 函数的使用对我来说似乎有点小技巧。 friend函数是否违反了封装的概念？

friend 函数的替代方法是什么？与仅使用 friend 相比，使用简单的帮助类/函数以及 setter 和 getter 成员函数是否有助于增加封装？

【问题讨论】：

嗯，一个只有一个 getter 和一个 setter 的简单类......与公开这些成员没有什么不同。你只是在对自己撒谎。朋友函数实际上更有助于封装，因为您直接定位谁可以访问您的成员。
@GuillaumeRacicot：但是与其他人共享这样的secret keys 会在以后的代码（尤其是大项目）中造成混乱 - 成员函数的常量等
When should you use 'friend' in C++?（通过快速搜索找到）可能会有所帮助。
Scott Meyers 写了许多关于成员函数、非成员朋友和非成员非朋友的文章 - 以及它们如何影响封装。你可以用谷歌找到一个公平的数字。随着时间的推移，他的一些思想细节发生了变化。请记住，封装本身并不是一个真正理想的属性 - 它是控制和本地化更改效果的一种方式，因此有助于提高灵活性（控制更改的能力）和稳健性（在进行更改时不会引入意外缺陷）等属性)。
如果您将封装程度衡量为编译器允许访问另一段代码的代码量，则此问题不是基于意见的。

标签： c++ oop encapsulation friend access-modifiers

【解决方案1】：

friend 函数是否违反了封装的概念？

事实上，没有。首先，请注意它并没有比public 成员更多地违反封装。 public 成员是否违反了封装的概念？显然不是。更重要的是，在许多情况下friend 增加了封装而不是违反它，因为它允许您将private 的东西维护为private，而不必使用public 成员在系统范围内公开数据，这使得它的整个概念是private 隐藏在肉眼之外。这与在您的代码中传递意图相反，并且应该在注意到时引发红旗。 friend 允许您缓解此问题，因为它可以让您准确控制谁可以访问这些被保留的成员 private 让每个人都知道他们是谁。 The C++ FAQ raises one example，您可以在其中使用 friend 来解决设计问题，这样您就可以控制对访问的访问，而根本没有增加访问代码的数量到private 部分。

难道不是一个简单的帮助类/函数以及 setter 和 getter 成员函数可以挽救这个设计缺陷吗？

嗯，使用辅助类肯定可以满足friend 所做的一些相同需求，但很多时候比仅使用friend 更加麻烦。关于函数或 getter/setter，我觉得这就像使用 public 成员直接暴露 private 成员，其缺点如上所述。

...还是不应该将其视为糟糕的设计实践？

作为结束说明，请尽量避免在这里提出主观问题，例如是否应该将某事视为 X。让我们坚持事实！ :)

【讨论】：

【解决方案2】：

友元函数是否违反了封装的概念

不，它增强封装，因为另一种方法是使成员public。

【讨论】：