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

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

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

会所

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

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

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

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

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

当不同的类(不是从另一个类继承一个类)正在使用另一个类的私有或受保护成员时，可以使用友情。

友元函数的典型用例是 在访问私有或受保护的两个不同的类之间进行 两者的成员。

来自http://www.cplusplus.com/doc/tutorial/inheritance/。

在这个例子中，非成员方法访问类的私有成员。这个方法必须在这个类中声明为类的友元。

// friend functions
#include <iostream>
using namespace std;

class Rectangle {
    int width, height;
  public:
    Rectangle() {}
    Rectangle (int x, int y) : width(x), height(y) {}
    int area() {return width * height;}
    friend Rectangle duplicate (const Rectangle&);
};

Rectangle duplicate (const Rectangle& param)
{
  Rectangle res;
  res.width = param.width*2;
  res.height = param.height*2;
  return res;
}

int main () {
  Rectangle foo;
  Rectangle bar (2,3);
  foo = duplicate (bar);
  cout << foo.area() << '\n';
  return 0;
}

我使用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;
}

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

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

很明显…