这可能不是一个实际的用例情况，但可能有助于说明类间朋友关系的使用。

会所

class ClubHouse {
public:
    friend class VIPMember; // VIP Members Have Full Access To Class
private:
    unsigned nonMembers_;
    unsigned paidMembers_;
    unsigned vipMembers;

    std::vector<Member> members_;
public:
    ClubHouse() : nonMembers_(0), paidMembers_(0), vipMembers(0) {}

    addMember( const Member& member ) { // ...code }   
    void updateMembership( unsigned memberID, Member::MembershipType type ) { // ...code }
    Amenity getAmenity( unsigned memberID ) { // ...code }

protected:
    void joinVIPEvent( unsigned memberID ) { // ...code }

}; // ClubHouse

会员班的

class Member {
public:
    enum MemberShipType {
        NON_MEMBER_PAID_EVENT,   // Single Event Paid (At Door)
        PAID_MEMBERSHIP,         // Monthly - Yearly Subscription
        VIP_MEMBERSHIP,          // Highest Possible Membership
    }; // MemberShipType

protected:
    MemberShipType type_;
    unsigned id_;
    Amenity amenity_;
public:
    Member( unsigned id, MemberShipType type ) : id_(id), type_(type) {}
    virtual ~Member(){}
    unsigned getId() const { return id_; }
    MemberShipType getType() const { return type_; }
    virtual void getAmenityFromClubHouse() = 0       
};

class NonMember : public Member {
public:
   explicit NonMember( unsigned id ) : Member( id, MemberShipType::NON_MEMBER_PAID_EVENT ) {}   

   void getAmenityFromClubHouse() override {
       Amenity = ClubHouse::getAmenity( this->id_ );
    }
};

class PaidMember : public Member {
public:
    explicit PaidMember( unsigned id ) : Member( id, MemberShipType::PAID_MEMBERSHIP ) {}

    void getAmenityFromClubHouse() override {
       Amenity = ClubHouse::getAmenity( this->id_ );
    }
};

class VIPMember : public Member {
public:
    friend class ClubHouse;
public:
    explicit VIPMember( unsigned id ) : Member( id, MemberShipType::VIP_MEMBERSHIP ) {}

    void getAmenityFromClubHouse() override {
       Amenity = ClubHouse::getAmenity( this->id_ );
    }

    void attendVIPEvent() {
        ClubHouse::joinVIPEvent( this->id );
    }
};

设施

class Amenity{};

如果你看看这些类之间的关系;会所拥有各种不同类型的会员资格和会员资格。成员都派生自超类或基类，因为它们都共享公共的ID和枚举类型，外部类可以通过基类中的访问函数访问它们的ID和类型。

然而，通过这种成员及其派生类的层次结构以及它们与ClubHouse类的关系，派生类中唯一具有“特殊特权”的是VIPMember类。基类和其他2个派生类不能访问ClubHouse的joinVIPEvent()方法，但VIP Member类拥有该特权，就好像它拥有对该事件的完全访问一样。

所以对于vip会员和ClubHouse，这是一个双向通道，而其他会员职业是有限的。

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

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

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

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

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

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

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

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

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

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

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

我使用friend的一个特定实例是在创建Singleton类时。friend关键字允许我创建一个访问器函数，这比总是在类上使用“GetInstance()”方法更简洁。

/////////////////////////
// Header file
class MySingleton
{
private:
    // Private c-tor for Singleton pattern
    MySingleton() {}

    friend MySingleton& GetMySingleton();
}

// Accessor function - less verbose than having a "GetInstance()"
//   static function on the class
MySingleton& GetMySingleton();


/////////////////////////
// Implementation file
MySingleton& GetMySingleton()
{
    static MySingleton theInstance;
    return theInstance;
}

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

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

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

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