在工作中，我们广泛地请朋友来测试代码。这意味着我们可以为主应用程序代码提供适当的封装和信息隐藏。但我们也可以有单独的测试代码，使用朋友来检查内部状态和数据进行测试。

可以说，我不会将friend关键字作为设计的重要组成部分。

另一种用法:friend(+虚拟继承)可以用来避免从一个类派生(又名:“make a class underivable”)=> 1,2

从2:

 class Fred;

 class FredBase {
 private:
   friend class Fred;
   FredBase() { }
 };

 class Fred : private virtual FredBase {
 public:
   ...
 }; 

友函数和类提供对类的私有和受保护成员的直接访问，以避免在一般情况下破坏封装。大多数使用是与ostream:我们希望能够键入:

Point p;
cout << p;

但是，这可能需要访问Point的私有数据，因此我们定义了重载操作符

friend ostream& operator<<(ostream& output, const Point& p);

然而，这里有明显的封装含义。首先，现在友类或函数可以完全访问类的所有成员，甚至不属于它的需要。其次，类和友元的实现现在交织在一起，以至于类中的内部更改可以破坏友元。

如果您将好友视为类的扩展，那么从逻辑上讲，这就不是问题。但是，在这种情况下，为什么有必要首先把朋友挖出来呢?

在不破坏封装的情况下，要实现“friends”所宣称的相同目标，可以这样做:

class A
{
public:
    void need_your_data(B & myBuddy)
    {
        myBuddy.take_this_name(name_);
    }
private:
    string name_;
};

class B
{
public:
    void print_buddy_name(A & myBuddy)
    {
        myBuddy.need_your_data(*this);
    }
    void take_this_name(const string & name)
    {
        cout << name;
    }
}; 

封装并没有被破坏，类B不能访问A中的内部实现，但结果与我们将B声明为A的朋友是一样的。 编译器将优化掉函数调用，因此这将导致与直接访问相同的指令。

我认为使用“朋友”是一个简单的捷径，有争议的好处，但一定的成本。

c++的创建者说这并没有破坏任何封装原则，我将引用他的话:

“朋友”是否违反封装? 不。但事实并非如此。“好友”是一种授予访问权限的显式机制，就像会员资格一样。你不能(在符合标准的程序中)在不修改类源的情况下授予自己对类的访问权。

很明显…

典型的例子是重载操作符<<。另一个常见的用法是允许助手或管理类访问您的内部。

下面是我从c++朋友那里听到的一些指导原则。最后一个尤其令人难忘。

你的朋友不是你孩子的朋友。 你孩子的朋友并不是你的朋友。 只有朋友才能碰你的隐私部位。

您使用私有/受保护/公共权限控制成员和函数的访问权限? 所以假设这3个层面中的每一个都很清楚，那么很明显我们遗漏了一些东西……

例如，将成员/函数声明为protected是非常通用的。你的意思是，这个功能对每个人来说都是遥不可及的(当然，继承的孩子除外)。但是异常呢?每个安全系统都让你有某种类型的“白名单”，对吗?

所以，“朋友”让你拥有坚如磐石的对象隔离的灵活性，但也允许为你认为合理的事情创造一个“漏洞”。

我想人们之所以说不需要它，是因为总有一种设计可以不需要它。我认为这类似于讨论全局变量:你永远不应该使用它们，总有办法不用它们……但在现实中，你会看到在某些情况下，这是(几乎)最优雅的方式……我认为朋友之间也是如此。

它实际上没有任何好处，除了让你在不使用设置函数的情况下访问成员变量

但这并不是正确的看法。 其理念是控制WHO可以访问什么，是否有设置功能与此关系不大。