Когда следует использовать слово «друг» в C++?

При реализации древовидных алгоритмов для класса в коде фреймворка, который нам предоставил профессор, был древовидный класс как друг класса узла.

На самом деле это не приносит никакой пользы, кроме как позволить вам получить доступ к переменной-члену без использования функции настройки.

Во-первых (ИМО) не слушайте людей, которые говорят, что friend бесполезен. Это полезно. Во многих ситуациях у вас будут объекты с данными или функциями, которые не предназначены для публичного доступа. Это особенно верно в отношении больших кодовых баз со многими авторами, которые могут быть только поверхностно знакомы с различными областями.

Существуют альтернативы спецификатору друга, но часто они громоздки (конкретные классы на уровне cpp / замаскированные определения типов) или не надежны (комментарии или соглашения об именах функций).

На ответ;

Спецификатор friend позволяет назначенному классу получить доступ к защищенным данным или функциям внутри класса, создавая оператор friend. Например, в приведенном ниже коде любой может спросить ребенка, как его имя, но только мать и ребенок могут изменить имя.

Вы можете продолжить этот простой пример, рассмотрев более сложный класс, такой как Window. Вполне вероятно, что в 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 );
};

Пример дерева - довольно хороший пример: Реализация объекта в нескольких разных классах без имея отношения наследования.

Возможно, вам также может понадобиться, чтобы конструктор был защищен и принудительно народ использовать фабрику "друга".

... Хорошо, честно говоря, вы можете жить без этого.

Вы контролируете права доступа для членов и функций, используя право Private / Protected / Public? Итак, если предположить, что идея каждого из этих трех уровней ясна, тогда должно быть ясно, что мы чего-то упускаем ...

Объявление члена / функции как защищенного, например, является довольно общим. Вы говорите, что эта функция недоступна для каждый (за исключением, конечно, унаследованного потомка). А как насчет исключений? каждая система безопасности позволяет вам иметь какой-то «белый список», не так ли?

Таким образом, друг позволяет вам иметь гибкость, обеспечивающую изоляцию твердых объектов, но позволяет создать «лазейку» для вещей, которые, по вашему мнению, оправданы.

Думаю, люди говорят, что это не нужно, потому что всегда есть дизайн, который обойдется без этого. Я думаю, это похоже на обсуждение глобальных переменных: вы никогда не должны их использовать, всегда есть способ обойтись без них ... но на самом деле вы видите случаи, когда это оказывается (почти) наиболее элегантным способом. .. Я думаю, что то же самое и с друзьями.

It doesn't really do any good, other than let you access a member variable without using a setting function

ну, это не совсем способ смотреть на это. Идея состоит в том, чтобы контролировать, кто может получить доступ к чему, наличие или отсутствие функция настройки имеет мало общего с этим.

Канонический пример - перегрузка оператора

Вот несколько советов о друзьях C++, которые я слышал. Последний особенно запомнился.

• Ваши друзья не друзья вашего ребенка.
• Друзья вашего ребенка - не ваши друзья.
• Только друзья могут прикасаться к вашим интимным частям.

@roo: инкапсуляция здесь не нарушена, потому что класс сам определяет, кто может получить доступ к его закрытым членам. Инкапсуляция будет нарушена, только если это может быть вызвано извне класса, например если ваш operator << будет провозглашать «Я друг класса foo».

friend заменяет использование public, а не private!

Собственно, FAQ по C++ уже отвечает на это.

Вы мог придерживаетесь самых строгих и чистейших принципов ООП и гарантируете, что ни у одного члена данных для любого класса даже нет аксессуары, так что все объекты должен будут единственными, кто может знать о своих данных, и единственный способ действовать на них - через косвенный Сообщения, т.е. методы.

Но даже в C# есть ключевое слово видимости внутренний, а в Java есть доступность уровня упаковка по умолчанию для некоторых вещей. C++ фактически приближается к идеалу ООП, минимизируя компромисс видимости в классе, указывая точно, какой другой класс и Только другие классы могут видеть в нем.

Я на самом деле не использую C++, но если бы в C# были друг, я бы использовал это вместо модификатора внутренний, глобального для сборки, который я действительно часто использую. На самом деле это не нарушает инкапсуляцию, потому что единица развертывания в .NET является - это сборка.

Но есть еще атрибут ВнутреннееAttribute (otherAssembly), который действует как механизм друг кросс-сборки. Microsoft использует это для визуальных сборок дизайнер.

Для выполнения TDD я много раз использовал ключевое слово friend в C++.

Может ли друг знать обо мне все?

Обновлено: я нашел этот ценный ответ о ключевом слове "друг" от Сайт Бьярне Страуструпа.

"Friend" is an explicit mechanism for granting access, just like membership.

To do TDD many times I've used 'friend' keyword in C++.
Can a friend know everything about me?

Нет, это только односторонняя дружба: `(

Один конкретный случай, когда я использую friend, - это создание классов Синглтон. Ключевое слово 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;
}

Что касается оператора>, то нет никаких оснований заводить дружбу с этими операторами. Это правда, что они не должны быть функциями-членами, но им также не нужно дружить.

Лучше всего создать общедоступные функции печати (ostream &) и чтения (istream &). Затем напишите оператор> в терминах этих функций. Это дает дополнительное преимущество, позволяя сделать эти функции виртуальными, что обеспечивает виртуальную сериализацию.

Friend пригодится, когда вы создаете контейнер и хотите реализовать итератор для этого класса.

На работе мы использовать друзей для тестирования кода, экстенсивно. Это означает, что мы можем обеспечить надлежащую инкапсуляцию и скрытие информации для основного кода приложения. Но также у нас может быть отдельный тестовый код, который использует друзей для проверки внутреннего состояния и данных для тестирования.

Достаточно сказать, что я бы не стал использовать ключевое слово friend как важный компонент вашего дизайна.

У нас возникла интересная проблема в компании, в которой я раньше работал, где мы использовали друга для достойного воздействия. Я работал в нашем отделе фреймворков, мы создали базовую систему уровня движка поверх нашей собственной ОС. Внутри у нас была структура классов:

         Game
        /    \
 TwoPlayer  SinglePlayer

Все эти классы были частью фреймворка и поддерживались нашей командой. Игры, выпускаемые компанией, были созданы на основе этой платформы, разработанной одним из детей Games. Проблема заключалась в том, что у Game были интерфейсы к различным вещам, к которым требовался доступ SinglePlayer и TwoPlayer, но которые мы не хотели открывать за пределами классов фреймворка. Решение заключалось в том, чтобы сделать эти интерфейсы приватными и разрешить доступ к ним TwoPlayer и SinglePlayer через дружбу.

По правде говоря, всю эту проблему можно было бы решить путем лучшей реализации нашей системы, но мы были заблокированы тем, что у нас было.

Еще одна распространенная версия примера Эндрю - ужасная кодовая пара.

parent.addChild(child);
child.setParent(parent);

Вместо того, чтобы беспокоиться о том, всегда ли обе строки выполняются вместе и в согласованном порядке, вы можете сделать методы закрытыми и иметь функцию друга для обеспечения согласованности:

class Parent;

class Object {
private:
    void setParent(Parent&);

    friend void addChild(Parent& parent, Object& child);
};

class Parent : public Object {
private:
     void addChild(Object& child);

     friend void addChild(Parent& parent, Object& child);
};

void addChild(Parent& parent, Object& child) {
    if ( &parent == &child ){ 
        wetPants(); 
    }
    parent.addChild(child);
    child.setParent(parent);
}

Другими словами, вы можете уменьшить размеры общедоступных интерфейсов и обеспечить соблюдение инвариантов, которые пересекаются с классами и объектами в дружественных функциях.

Друзья также полезны для обратных звонков. Вы можете реализовать обратные вызовы как статические методы

class MyFoo
{
private:
    static void callback(void * data, void * clientData);
    void localCallback();
    ...
};

где callback вызывает внутренний вызов localCallback, а в clientData есть ваш экземпляр. Я считаю,

или же...

class MyFoo
{
    friend void callback(void * data, void * callData);
    void localCallback();
}

Это позволяет другу быть определенным исключительно в cpp как функция в стиле c, а не загромождать класс.

Точно так же шаблон, который я видел очень часто, заключается в том, чтобы поместить все закрытые члены В самом деле класса в другой класс, который объявлен в заголовке, определен в cpp и добавлен в друзья. Это позволяет кодировщику скрыть большую часть сложности и внутренней работы класса от пользователя заголовка.

В шапке:

class MyFooPrivate;
class MyFoo
{
    friend class MyFooPrivate;
public:
    MyFoo();
    // Public stuff
private:
    MyFooPrivate _private;
    // Other private members as needed
};

В cpp,

class MyFooPrivate
{
public:
   MyFoo *owner;
   // Your complexity here
};

MyFoo::MyFoo()
{
    this->_private->owner = this;
}

Становится легче скрывать вещи, которые нижестоящие компании не должны видеть таким образом.

Ключевое слово friend имеет ряд полезных применений. Вот два варианта использования, которые мне сразу видны:

Определение друга

Определение друга позволяет определять функцию в области класса, но функция не будет определяться как функция-член, а как свободная функция включающего пространства имен, и не будет видна обычно, за исключением поиска, зависящего от аргумента. Это делает его особенно полезным при перегрузке операторов:

namespace utils {
    class f {
    private:
        typedef int int_type;
        int_type value;

    public:
        // let's assume it doesn't only need .value, but some
        // internal stuff.
        friend f operator+(f const& a, f const& b) {
            // name resolution finds names in class-scope. 
            // int_type is visible here.
            return f(a.value + b.value);
        }

        int getValue() const { return value; }
    };
}

int main() {
    utils::f a, b;
    std::cout << (a + b).getValue(); // valid
}

Частный базовый класс CRTP

Иногда вы обнаруживаете, что политике нужен доступ к производному классу:

// possible policy used for flexible-class.
template<typename Derived>
struct Policy {
    void doSomething() {
        // casting this to Derived* requires us to see that we are a 
        // base-class of Derived.
        some_type const& t = static_cast<Derived*>(this)->getSomething();
    }
};

// note, derived privately
template<template<typename> class SomePolicy>
struct FlexibleClass : private SomePolicy<FlexibleClass> {
    // we derive privately, so the base-class wouldn't notice that, 
    // (even though it's the base itself!), so we need a friend declaration
    // to make the base a friend of us.
    friend class SomePolicy<FlexibleClass>;

    void doStuff() {
         // calls doSomething of the policy
         this->doSomething();
    }

    // will return useful information
    some_type getSomething();
};

Вы найдете не надуманный пример в ответе это. Другой код, использующий это, находится в ответе это. База CRTP использует свой указатель this, чтобы иметь возможность доступа к полям данных производного класса с помощью указателей-членов-данных.

Короткий ответ: используйте друг, когда на самом деле это инкапсуляция улучшается. Улучшение читабельности и удобства использования (операторы> являются каноническим примером) также является хорошей причиной.

Что касается примеров улучшения инкапсуляции, хорошими кандидатами являются классы, специально разработанные для работы с внутренними компонентами других классов (на ум приходят тестовые классы).

Я использую ключевое слово friend только для защищенных функций unittest. Некоторые скажут, что не стоит тестировать защищенный функционал. Однако я считаю этот инструмент очень полезным при добавлении новых функций.

Однако я не использую ключевое слово непосредственно в объявлениях классов, вместо этого я использую изящный шаблонный хак, чтобы добиться этого:

template<typename T>
class FriendIdentity {
public:
  typedef T me;
};

/**
 * A class to get access to protected stuff in unittests. Don't use
 * directly, use friendMe() instead.
 */
template<class ToFriend, typename ParentClass>
class Friender: public ParentClass
{
public:
  Friender() {}
  virtual ~Friender() {}
private:
// MSVC != GCC
#ifdef _MSC_VER
  friend ToFriend;
#else
  friend class FriendIdentity<ToFriend>::me;
#endif
};

/**
 * Gives access to protected variables/functions in unittests.
 * Usage: <code>friendMe(this, someprotectedobject).someProtectedMethod();</code>
 */
template<typename Tester, typename ParentClass>
Friender<Tester, ParentClass> & 
friendMe(Tester * me, ParentClass & instance)
{
    return (Friender<Tester, ParentClass> &)(instance);
}

Это позволяет мне делать следующее:

friendMe(this, someClassInstance).someProtectedFunction();

Работает по крайней мере на GCC и MSVC.

edit: Reading the faq a bit longer I like the idea of the << >> operator overloading and adding as a friend of those classes, however I am not sure how this doesn't break encapsulation

Как бы это нарушило инкапсуляцию?

Вы нарушаете инкапсуляцию, когда разрешаете неограниченный доступ к члену данных. Рассмотрим следующие классы:

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. Как это вообще имеет смысл? (подсказка: это не так)

Нижняя линия: Инкапсуляция - это возможность контролировать, какие функции могут получить доступ к закрытым членам. Это нет о том, где именно расположены определения этих функций.

Другое использование: друг (+ виртуальное наследование) может использоваться, чтобы избежать наследования от класса (иначе: «сделать класс недоступным») => 1, 2

Из 2:

 class Fred;

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

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

Создатель C++ говорит, что не нарушает принципа инкапсуляции, и я процитирую его:

Does "friend" violate encapsulation? No. It does not. "Friend" is an explicit mechanism for granting access, just like membership. You cannot (in a standard conforming program) grant yourself access to a class without modifying its source.

Более чем понятно ...

Дружественные функции и классы обеспечивают прямой доступ к закрытым и защищенным членам класса, чтобы избежать нарушения инкапсуляции в общем случае. Чаще всего используется ostream: мы хотели бы иметь возможность набирать:

Point p;
cout << p;

Однако для этого может потребоваться доступ к личным данным Point, поэтому мы определяем перегруженный оператор

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

Однако есть очевидные последствия инкапсуляции. Во-первых, теперь класс или функция друга имеют полный доступ ко ВСЕМ членам класса, даже к тем, которые не относятся к его потребностям. Во-вторых, реализации класса и друга теперь связаны до такой степени, что внутреннее изменение в классе может сломать друга.

Если вы рассматриваете друга как продолжение класса, то, с логической точки зрения, это не проблема. Но в таком случае, зачем вообще нужно было изгонять друга?

Чтобы добиться того же, чего хотят достичь «друзья», но без нарушения инкапсуляции, можно сделать следующее:

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, и, как и вы, я использовал его очень редко. Ниже приведены некоторые примечания по использованию friend и альтернатив.

Допустим, вы хотите сравнить два объекта, чтобы убедиться, что они равны. Вы могли либо:

• Используйте методы доступа для сравнения (проверьте каждый ivar и определите равенство).
• Или вы можете получить доступ ко всем участникам напрямую, сделав их общедоступными.

Проблема с первым вариантом заключается в том, что это может быть ОЧЕНЬ много средств доступа, что (немного) медленнее, чем прямой доступ к переменным, сложнее для чтения и громоздко. Проблема со вторым подходом заключается в том, что вы полностью нарушаете инкапсуляцию.

Было бы неплохо, если бы мы могли определить внешнюю функцию, которая все еще могла бы получать доступ к закрытым членам класса. Мы можем сделать это с помощью ключевого слова friend:

class Beer {
public:
    friend bool equal(Beer a, Beer b);
private:
    // ...
};

Метод equal(Beer, Beer) теперь имеет прямой доступ к закрытым членам a и b (которыми могут быть char *brand, float percentAlcohol и т. д. Это довольно надуманный пример, вы бы скорее применили friend к перегруженному == operator, но мы еще вернемся к этому.

Несколько замечаний:

• friend НЕ является функцией-членом класса
• Это обычная функция со специальным доступом к закрытым членам класса.
• Не заменяйте все аксессоры и мутаторы друзьями (вы также можете сделать все public!)
• Дружба не взаимна
• Дружба непостоянна
• Дружба не передается по наследству
• Или, как C++ FAQ объясняет: «Просто потому, что я предоставляю вам доступ ко мне для дружбы, это автоматически не дает вашим детям доступа ко мне, не предоставляет автоматически вашим друзьям доступ ко мне и не предоставляет мне автоматически доступ к вам».

Я действительно использую friends только тогда, когда намного сложнее сделать наоборот. В качестве другого примера, многие векторные математические функции часто создаются как friends из-за совместимости Mat2x2, Mat3x3, Mat4x4, Vec2, Vec3, Vec4 и т. д. И гораздо проще дружить, чем использовать везде аксессоры. Как уже указывалось, friend часто применяется к << (действительно удобен для отладки), >> и, возможно, к оператору ==, но также может использоваться для чего-то вроде этого:

class Birds {
public:
    friend Birds operator +(Birds, Birds);
private:
    int numberInFlock;
};


Birds operator +(Birds b1, Birds b2) {
    Birds temp;
    temp.numberInFlock = b1.numberInFlock + b2.numberInFlock;
    return temp;
}

Как я уже сказал, я не очень часто использую friend, но время от времени это именно то, что вам нужно. Надеюсь это поможет!

Вы можете использовать дружбу, когда разные классы (не наследующие один от другого) используют закрытые или защищенные члены другого класса.

Typical use cases of friend functions are operations that are conducted between two different classes accessing private or protected members of both.

от 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;
}

Я нашел удобное место для использования доступа друзей: Unittest частных функций.

В C++ ключевое слово friend полезно при перегрузке оператора и создании моста. 1.) Ключевое слово Friend в перегрузке оператора:
Пример перегрузки оператора: Допустим, у нас есть класс «Point», который имеет две плавающие переменные
«x» (для x-координаты) и «y» (для y-координаты). Теперь нам нужно перегрузить "<<" (оператор извлечения), чтобы при вызове "cout << pointobj" он выводил координаты x и y (где pointobj - объект класса Point). Для этого у нас есть два варианта:

   1.Overload "operator <<()" function in "ostream" class.
   2.Overload "operator<<()" function in "Point" class.

   1.Using ostream object cout.As: cout.operator&lt&lt(Pointobj) (form ostream class).
   2.Call without an object.As: operator&lt&lt(cout, Pointobj) (from Point class).

Потому что мы реализовали перегрузку в классе Point. Итак, чтобы вызвать эту функцию без объекта, мы должны добавить ключевое слово "friend", потому что мы можем вызвать функцию друга без объекта. Теперь объявление функции будет As:
"friend ostream &operator<<(ostream &cout, Point &pointobj);"

2.) Ключевое слово друга при создании моста:
Предположим, нам нужно создать функцию, в которой мы должны получить доступ к закрытому члену двух или более классов (обычно называемых «мостом»). Как это сделать:
Чтобы получить доступ к закрытому члену класса, он должен быть членом этого класса. Теперь, чтобы получить доступ к закрытому члену другого класса, каждый класс должен объявить эту функцию как функцию друга. Например : Предположим, есть два класса A и B. Функция "funcBridge()" хочет получить доступ к закрытому члену обоих классов. Затем оба класса должны объявить "funcBridge()" как:
friend return_type funcBridge(A &a_obj, B & b_obj);

Я думаю, это поможет понять ключевое слово друга.

Возможно, я что-то пропустил из приведенных выше ответов, но еще одна важная концепция инкапсуляции - это сокрытие реализации. Уменьшение доступа к частным элементам данных (деталям реализации класса) позволяет значительно упростить модификацию кода позже. Если друг напрямую обращается к личным данным, любые изменения в полях данных реализации (личные данные) нарушают код доступа к этим данным. Использование методов доступа в основном устраняет это. Думаю, довольно важно.

Это может не быть реальной ситуацией варианта использования, но может помочь проиллюстрировать использование друга между классами.

Клубный дом

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{};

Если вы посмотрите на отношения этих классов здесь; ClubHouse предлагает различные типы членства и доступа к членству. Все члены являются производными от суперкласса или базового класса, поскольку все они имеют общий идентификатор и перечислимый тип, которые являются общими, а внешние классы могут получить доступ к своим идентификаторам и типам с помощью функций доступа, которые находятся в базовом классе.

Однако благодаря такой иерархии членов и его производных классов и их взаимосвязи с классом ClubHouse единственным производным классом, имеющим «особые привилегии», является класс VIPMember. Базовый класс и два других производных класса не могут получить доступ к методу joinVIPEvent () ClubHouse, но класс VIP-члена имеет эту привилегию, как если бы он имел полный доступ к этому событию.

Таким образом, с VIPMember и ClubHouse это улица с двусторонним доступом, где другие классы участников ограничены.

Как говорится в ссылке на объявление друга:

The friend declaration appears in a class body and grants a function or another class access to private and protected members of the class where the friend declaration appears.

Напоминаем, что в некоторых ответах есть технические ошибки, в которых говорится, что friend может посещать только членов защищенный.