朋友功能是否违反封装？

Question

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

friend函数的替代方法是什么？与仅使用friend相比，将简单的帮助程序类/函数与 setter 和 getter 成员函数一起使用会增加封装吗？

Answer 1

  

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

实际上，不是。首先，请注意，它没有比public成员更多地违反封装。 public成员是否违反封装概念？明显不是。更重要的是，在许多情况下，friend增加了封装而不是违反了封装，因为它使您可以将private的内容保持为private，而不必使用{{ 1}}个成员，这使得public的整个概念被肉眼隐藏。这与在代码中传递意图相反，并且在被注意到时应升起红色标记。 private可以减轻您的麻烦，因为它使您可以控制谁可以访问这些friend被保留的成员，让所有人都知道他们是谁。 The C++ FAQ raises one example中，您可以使用private解决一个设计问题，以便对无法完全增加 数量的点进行访问控制。可以访问friend部分的代码。

  

简单的辅助类/函数以及setter和getter成员函数是否可以挽救此设计缺陷？

好吧，使用辅助类肯定可以满足private的一些相同需求，但是很多时候比仅仅使用friend麻烦得多。关于函数或getter / setter，在我看来，就像使用 public 成员直接公开 private 成员一样，其缺点已在上面进行了描述。

  

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

作为结尾，请尝试在此处避免主观问题，例如是否应将某些事物视为X。让我们坚持事实！ ：）

Answer 2

  

朋友功能是否违反了封装的概念

否，它增强了封装，因为替代方法是使成员成为public成员。