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

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

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

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

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

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

友函数和类提供对类的私有和受保护成员的直接访问，以避免在一般情况下破坏封装。大多数使用是与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的朋友是一样的。 编译器将优化掉函数调用，因此这将导致与直接访问相同的指令。

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

在为类实现树算法时，教授给我们的框架代码将树类作为节点类的朋友。

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

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

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

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

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

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

您可以坚持最严格和最纯粹的OOP原则，并确保任何类的数据成员都没有访问器，这样所有对象都必须是唯一可以知道它们的数据的对象，并且对它们进行操作的唯一方法是通过间接消息(即方法)。

但即使是c#也有一个内部可见性关键字，Java也有默认的包级可访问性。c++实际上更接近于OOP的理想，它通过精确地指定哪些其他类或只有其他类可以看到一个类，从而最大限度地减少了类的可见性。

我不太使用c++，但如果c#有朋友，我会用它来代替我经常使用的汇编全局内部修饰符。它并没有真正打破封装，因为。net中的部署单元是一个程序集。

但是还有InternalsVisibleToAttribute(otherAssembly)，它的作用类似于跨组装的友元机制。微软将此用于可视化设计器程序集。