C++ C+中的Friend类+；

在这里我不是很理解这个概念，或者我是对的。。。。让我们以这个“朋友”类为例：

class MyClass{
friend class AnotherClass;
private:
       int secret;
}

class AnotherClass{
public:
      void getSecret(MyClass mc){
          return mc.secret;
      }
}

---

所以是的。。。在上面的代码中，如果您这样做，它将实际工作。。。但总的来说，为什么不能一直使用getter和setter而不是friend类呢？使用friend类的原因是因为“冗长”？

friend

用于不想向所有人公开getter/setter/internal，而只向单个类公开的情况。所以它是一种封装工具

例如，如果您在

MyClass

中提供了一个公共

getSecret

，那么每个人都可以访问该私有变量，即使他们不应该知道它。这破坏了封装

friend

可以解决这个问题，这样只有那些需要知道

secret

的类才能访问它

---

正如@nicomp所说，“这就像给你的物理朋友一把你房子的钥匙，但你不知道他们会用它做什么”。因此，

friend

类可以无限访问它的好友所在的类的所有内部。这是不幸的，但这里的关键（不是双关语）是使类尽可能小，这样就不会成为问题，这也符合单一责任原则。

考虑一下我最近遇到的以下用例：我将一些代码从一个类重构到另一个类。这个新类必须访问原始类中的成员，但我不想通过public getter提供，以避免其他客户机对这些成员进行干扰。在这种情况下，我非常欢迎C++友谊机制

然而，这些用例很少（希望，否则您的软件架构可能有问题），我尽量避免使用，因为它是最紧密的耦合形式。

公共getter或setter允许任何人访问。它们有一些用途，特别是在某些属性发生更改时维护类不变量，但类似于以下代码的getter/setter对并不比公共成员变量更好：

getX（）

和

setX（）

函数只提供对

x

的访问。每个人都可以使用它们，因此任何人都可以更改

x

的值。那就没有必要把它保密了

相反，如果只有某些类或函数需要能够更改

x

，您可以让它们成为类

A

的朋友。这限制了只能访问那些朋友，而不是给每个人

因此，

friend

是一种封装工具，允许封装比“仅我自己的类”（私有成员）或“仅我的类及其派生的类”（受保护的成员）更广泛。朋友不必在同一个类层次结构中（它根本不必是类；函数可以是朋友），但它仍然允许您仅限制对实际需要它的东西的访问

请注意，与getter和setter一样，它应该少用。封装是一件好事，在可能的情况下，类的私有成员应该保持私有<代码>朋友是一种允许您选择性地授予访问权限的工具，但是您应该始终仔细考虑是否需要授予该访问权限，或者需要它的函数/类是否作为类成员更好，

不要忘记测试。 友元类/方法可以非常成功地用于测试类功能中的中间状态

---

这些对于某些类型的复制构造函数也很有用，因为要复制的类不是目标类的直接祖先。

@AmanuelBogale是的，要点是相同的。不过，我想我提供了一些额外的背景知识？@AmanuelBogale，这完全取决于你。这可能会有帮助……哎呀，我发现我太懒了，不想把它编辑到我的答案中，但如果有人在乎的话，那就是SFML，它非常巧妙地使用了

friend

。

class A {
 public:
  int getX() const { return x; };
  void setX(int x_) { x = x_; };
 private:
  int x;
};