编辑:阅读faq有点长，我喜欢<< >>操作符重载和添加作为这些类的朋友的想法，但我不确定这如何不打破封装

它将如何破坏封装?

当允许对数据成员进行不受限制的访问时，就打破了封装。考虑以下类:

class c1 {
public:
  int x;
};

class c2 {
public:
  int foo();
private:
  int x;
};

class c3 {
  friend int foo();
private:
  int x;
};

C1显然没有封装。任何人都可以读取和修改其中的x。我们没有办法实施任何形式的访问控制。

C2明显被封装了。没有对x的公共访问。你所能做的就是调用foo函数，它对类执行一些有意义的操作。

c3吗?它的封装程度低吗?它是否允许无限制地访问x?它是否允许未知函数访问?

不。它只允许一个函数访问类的私有成员。就像c2一样。就像c2一样，有访问权的函数不是“某个随机的未知函数”，而是“类定义中列出的函数”。就像c2一样，通过查看类定义，我们可以看到拥有访问权限的完整列表。

那么，这到底是如何减少封装的呢?同样数量的代码可以访问类的私有成员。类定义中列出了所有具有访问权限的人。

Friend不会破坏封装。这让一些Java程序员感到不舒服，因为当他们说“面向对象”时，他们实际上指的是“Java”。当他们说“封装”时，他们并不是说“必须保护私有成员不受任意访问”，而是说“在Java类中，唯一能够访问私有成员的函数是类成员”，尽管出于几个原因，这完全是无稽之谈。

首先，如上所述，它限制太大。没有理由不允许朋友方法做同样的事情。

第二，限制不够。考虑第四个类:

class c4 {
public:
  int getx();
  void setx(int x);
private:
  int x;
};

根据上述Java思想，这是完美封装的。 但是，它允许任何人读取和修改x，这有什么意义呢?(提示:事实并非如此)

底线: 封装是关于能够控制哪些函数可以访问私有成员。这与这些函数的定义具体位于何处无关。

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

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

首先(依我看)不要听那些说朋友没用的人。它是有用的。在许多情况下，您将拥有具有不打算公开可用的数据或功能的对象。对于许多作者可能只是表面上熟悉不同领域的大型代码库尤其如此。

友元说明符也有替代方案，但通常都很麻烦(cppp级别的具体类/掩码类型定义)，或者不是万无一错(注释或函数名约定)。

在答案上;

友元说明符允许指定类访问发出友元语句的类内受保护的数据或功能。例如，在下面的代码中，任何人都可以询问孩子的名字，但只有母亲和孩子可以更改名字。

您可以通过考虑一个更复杂的类(如Window)来进一步考虑这个简单的示例。一个窗口很可能会有许多不应该被公开访问的函数/数据元素，但是被相关的类(如WindowManager)所需要。

class Child
{
//Mother class members can access the private parts of class Child.
friend class Mother;

public:

  string name( void );

protected:

  void setName( string newName );
};

树的例子是一个很好的例子: 在一些不同的类中实现一个对象 具有继承关系。

也许您还需要它具有一个构造函数protected和force 人们用你的“朋友”工厂。

．.． 好吧，坦白地说，没有它你也能生活。

我发现了一个使用好友访问的方便地方:私有函数的Unittest。

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

会所

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，这是一个双向通道，而其他会员职业是有限的。