Коли слід використовувати "friend" в C ++?

Я читав відповіді на C ++ і мені було цікаво friendдекларацію. Я особисто ніколи його не використовував, проте мені цікаво вивчити мову.

Який хороший приклад використання friend?

Читання питань FAQ трохи довше мені подобається ідея << >>перевантаження оператора та додавання їх як друга цих класів. Однак я не впевнений, як це не порушує інкапсуляцію. Коли ці винятки можуть залишатися в межах суворості, яка є OOP?

По-перше (ІМО) не слухають людей, які кажуть, що friendце не корисно. Це корисно. У багатьох ситуаціях у вас з'являться об'єкти з даними або функціональними можливостями, які не призначені для загального доступу. Особливо це стосується великих кодових баз з багатьма авторами, які, можливо, лише поверхнево знайомі з різних областей.

Є альтернативи специфікатору друзів, але часто вони громіздкі (конкретні класи на рівні cpp / маскуються typedefs) або не є надійними (коментарі чи умовні назви функцій).

На відповідь;

Специфікатор friendдозволяє вказаному класу отримати доступ до захищених даних або функціональних можливостей у класі, роблячи заяву про друзів. Наприклад, у наведеному нижче коді будь-хто може запитати дитину про своє ім'я, але тільки мати та дитина можуть змінити ім'я.

Ви можете взяти цей простий приклад далі, розглянувши більш складний клас, наприклад, Window. Цілком ймовірно, що у вікні буде багато елементів функції / даних, які не повинні бути загальнодоступними, але ARE потрібні відповідному класу, наприклад, 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 );
};

На роботі ми використовуємо друзів для тестування коду , широко. Це означає, що ми можемо забезпечити належну інкапсуляцію та приховування інформації для основного коду програми. Але також ми можемо мати окремий тестовий код, який використовує друзів для перевірки внутрішнього стану та даних для тестування.

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

friendКлючове слово має кілька хороших цілей. Ось два види, які мені відразу видно:

Визначення друга

Визначення 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 передає цей покажчик, щоб мати доступ до полів даних похідного класу за допомогою покажчиків data-member.

@roo : Інкапсуляція тут не порушена, оскільки сам клас диктує, хто може отримати доступ до своїх приватних членів. Інкапсуляція буде порушена лише в тому випадку, якщо це може бути викликано поза класом, наприклад, якщо ви operator <<проголосите "Я друг класу foo".

friendзамінює використання public, а не використання private!

Насправді, відповіді на C ++ вже відповідають на це .

Канонічний приклад - перевантаження оператора <<. Ще одне поширене використання - дозволити довідковому чи адміністраторському класу отримати доступ до ваших служб.

Ось кілька рекомендацій, які я чув про друзів C ++. Останній особливо запам'ятовується.

• Ваші друзі не є друзями вашої дитини.
• Друзі вашої дитини - це не ваші друзі.
• Тільки друзі можуть торкатися ваших приватних частин.

редагувати: читання файлу трохи довше Мені подобається ідея перезавантаження оператора << >> і додавання його як друга цих класів, проте я не впевнений, як це не порушує інкапсуляцію

Як би це порушило інкапсуляцію?

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

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 відчувати себе некомфортно, тому що, коли вони говорять "OOP", це насправді означає "Java". Коли вони кажуть "інкапсуляція", вони не означають, що "приватні члени повинні бути захищені від довільного доступу", але "клас Java, де єдині функції, які мають змогу отримати доступ до приватних членів, є членами класу", навіть якщо це повна дурниця для кілька причин .

По-перше, як уже показано, це занадто обмежує. Немає причини, чому дружні методи не повинні дозволяти робити те саме.

По- друге, це не є обмежувальним досить . Розглянемо четвертий клас:

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

Це, згідно з вищезазначеним менталітетом Java, ідеально інкапсульоване. І все ж, він дозволяє абсолютно будь-кому читати та змінювати х . Як це навіть має сенс? (натяк: Це не так)

Підсумок: інкапсуляція - це можливість контролювати, які функції можуть отримати доступ до приватних членів. Справа не в тому, де саме знаходяться визначення цих функцій.

Ще одна поширена версія прикладу Ендрю, жахливий кодовий пакет

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

Іншими словами, ви можете зменшити загальнодоступні інтерфейси та застосувати інваріанти, які перетинають класи та об'єкти у функції друзів.

Ви контролюєте права доступу членів і функцій, використовуючи приватне / захищене / публічне право? тож якщо припустити, що ідея кожного з цих трьох рівнів є зрозумілою, тоді повинно бути зрозуміло, що нам щось не вистачає ...

Оголошення члена / функції як захищеного, наприклад, є досить загальним. Ви говорите, що ця функція недосяжна для всіх (за винятком спадкової дитини). А як щодо винятків? кожна система безпеки дозволяє вам мати певний тип "білого списку"?

Тож друг дозволяє вам мати гнучкість ізоляції твердих об'єктів, але дозволяє створити «лазівку» для речей, які, на вашу думку, є виправданими.

Я думаю, люди кажуть, що це не потрібно, тому що завжди є дизайн, який обійдеться без нього. Я думаю, це схоже на обговорення глобальних змінних: ніколи не слід їх використовувати. Завжди існує спосіб обійтися без них ... але насправді ви бачите випадки, коли це в кінцевому підсумку є (майже) найелегантнішим способом. .. Я думаю, що це той самий випадок із друзями.

Це насправді не приносить користі, крім того, що ви можете отримати доступ до змінної члена без використання функції налаштування

добре, це не зовсім так, як на це дивитися. Ідея полягає в тому, щоб контролювати ВООЗ, який може отримати доступ до того, що має, чи не налаштовує функцію , мало спільного з цим.

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

Друг стане в нагоді, коли ви будуєте контейнер і хочете реалізувати ітератор для цього класу.

У нас з'явилася цікава проблема у компанії, в якій я раніше працював, де ми використовували друга, щоб гідно вплинути. Я працював у нашому базовому відділі, ми створили базову систему рівня двигуна над нашою власною ОС. Всередині у нас була структура класу:

         Game
        /    \
 TwoPlayer  SinglePlayer

Усі ці заняття були частиною основи і підтримувалися нашою командою. Ігри, що виробляються компанією, були побудовані на основі цієї основи, що походить від одного з дітей Ігор. Проблема полягала в тому, що у грі були інтерфейси до різних речей, до яких потрібен доступ SinglePlayer та TwoPlayer, але ми не хотіли виставляти її поза рамками класів. Рішення полягало в тому, щоб зробити ці інтерфейси приватними та дозволити TwoPlayer та SinglePlayer отримати доступ до них через дружбу.

Істинно все це питання можна було б вирішити шляхом кращого впровадження нашої системи, але ми були замкнені у тому, що у нас було.

Коротка відповідь буде: використовуйте друга, коли він насправді покращиться інкапсуляцію. Поліпшення читабельності та зручності використання (оператори << і >> є канонічним прикладом) також є вагомою причиною.

Що стосується прикладів вдосконалення інкапсуляції, то класи, спеціально розроблені для роботи з представниками інших класів (тестові класи приходять на думку), є хорошими кандидатами.

Творець C ++ каже, що не порушує жодного принципу інкапсуляції, і я його цитую:

Чи порушує "друг" інкапсуляцію? Ні, це не є. "Друг" - це явний механізм надання доступу, як і членство. Ви не можете (у стандартній відповідній програмі) надати собі доступ до класу, не змінюючи його джерело.

Більш ніж зрозуміло ...

Ще одне використання: friend (+ віртуальна спадщина) може бути використаний, щоб уникнути походження з класу (aka: "зробити клас неприйнятним") => 1 , 2

З 2 :

 class Fred;

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

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

Щоб робити TDD багато разів, я використовував ключове слово "friend" в C ++.

Може друг знає про мене все?

Оновлено: я знайшов цю цінну відповідь про ключове слово "друг" з сайту Bjarne Stroustrup .

"Друг" - це явний механізм надання доступу, як і членство.

Ви повинні бути дуже обережними щодо того, коли / де ви використовуєте friendключове слово, і, як і ви, я використовував його дуже рідко. Нижче наведено кілька приміток щодо використання friendта альтернатив.

Скажімо, ви хочете порівняти два об'єкти, щоб побачити, чи рівні вони. Ви можете:

• Використовуйте методи аксесуара для порівняння (перевіряйте кожен ivar і визначайте рівність).
• Або ви можете отримати доступ до всіх членів безпосередньо, оприлюднивши їх.

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

Що було б добре, якби ми могли визначити зовнішню функцію, яка все-таки могла б отримати доступ до приватних членів класу. Це можна зробити за допомогою friendключового слова:

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

Метод в equal(Beer, Beer)даний час має прямий доступ до aі b«s приватних користувачів (які можуть бути char *brand, float percentAlcoholі т.д. Це досить надуманий приклад, ви б швидше звернутися friendдо перевантаженим == operator, але ми повернемося до цього.

Кілька речей, які слід зазначити:

• A friendНЕ є функцією члена класу
• Це звичайна функція зі спеціальним доступом до приватних членів класу
• Не замінюйте всіх аксесуарів та мутаторів друзями (ви можете все зробити public!)
• Дружба не є взаємною
• Дружба не перехідна
• Дружба не передається у спадок
• Або, як пояснює FAQ C ++ : "Просто тому, що я надаю вам доступ до дружби до мене, автоматично не надає вашим дітям доступ до мене, не автоматично надає вашим друзям доступ до мене і не дає автоматично мені доступ до вас" . "

Я справді використовую лише 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дуже часто, але раз у раз це саме те, що потрібно. Сподіваюся, це допомагає!

Що стосується оператора << і оператора >>, то немає вагомих причин для того, щоб подружити цих операторів. Це правда, що вони не повинні бути членами функцій, але вони також не повинні бути друзями.

Найкраще це створити публічні функції друку (ostream &) та читання (istream &). Потім запишіть оператор << і оператор >> в рамках цих функцій. Це дає додаткову перевагу, що дозволяє зробити ті функції віртуальними, що забезпечує віртуальну серіалізацію.

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

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

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 принаймні.

У C ++ ключове слово "друг" корисне для перевантаження оператора та створення мосту.

1.) Ключове слово Друга при перевантаженні оператора:
Прикладом перевантаження оператора є: Скажімо, у нас є клас "Точка", який має дві поплавкові змінної
"x" (для x-координати) та "y" (для y-координати). Тепер нам доведеться перевантажувати "<<"(оператор видобутку) таким, що якщо ми зателефонуємо"cout << pointobj" він надрукує координати x і y (де pointobj є об'єктом класу Point). Для цього у нас є два варіанти:

   1.Завантажте функцію "оператор << ()" у класі "ostream".
   2.Завантажте функцію "оператор << ()" у класі "Точка".

   1. Використання ostream об'єкта cout.As: cout.operator << (Pointobj) (форма класу ostream). 
   2.Виклик без об'єкта. Як: оператор << (cout, Pointobj) (від класу Point).

Тому що ми здійснили перевантаження в класі Point. Отже, щоб викликати цю функцію без об'єкта, ми повинні додати "friend"ключове слово, оскільки ми можемо викликати функцію друга без об’єкта. Тепер декларація функції буде виглядати як:
"friend ostream &operator<<(ostream &cout, Point &pointobj);"

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

Я думаю, що це допоможе зрозуміти ключове слово друга.

Як зазначається в декларації про друзів :

Декларація про друзі з'являється в тілі класу і надає функції або іншому класу доступ до приватних і захищених членів класу, де відображається декларація про друга.

Тож як нагадування, у деяких відповідях є технічні помилки, які говорять, що friendвідвідувати можуть лише захищені члени.

Приклад дерева - досить хороший приклад: наявність об'єкта, реалізованого в декількох різних класах, не маючи спадкових відносин.

Можливо, вам це також може знадобитися, щоб конструктор захистив і змусив людей використовувати вашу фабрику "друга".

... Гаразд, відверто кажучи, можна без цього жити.

Щоб робити TDD багато разів, я використовував ключове слово "friend" в C ++.
Може друг знає про мене все?

Ні, це єдиний спосіб дружби: `(

Один конкретний екземпляр, який я використовую, 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;
}

Функції та класи друзів забезпечують прямий доступ до приватних та захищених членів класу, щоб уникнути порушення інкапсуляції в загальному випадку. Найбільше використання використовується в 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 другом А. Компілятор оптимізує виклики функцій, тож це призведе до того ж інструкції як прямий доступ.

Я думаю, що використання "друга" - це просто ярлик із суперечливою вигодою, але певна вартість.

Це може не бути фактичним випадком використання, але може допомогти проілюструвати використання друга між класами.

Будинок клубу

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 Member має таку привілей, як ніби він має повний доступ до цієї події.

Тож з VIPMember та ClubHouse це двостороння вулиця доступу, де інші класи членів обмежені.

При впровадженні алгоритмів дерев для класу рамковий код, який нам дав проф, мав клас дерева як друга класу вузлів.

Це насправді не приносить користі, крім того, що ви можете отримати доступ до змінної члена без використання функції налаштування.

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

Типовими випадками використання функцій друзів є операції, які проводяться між двома різними класами, що мають доступ до приватних або захищених членів обох.

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

Можливо, я пропустив щось із наведених вище відповідей, але ще одна важлива концепція інкапсуляції - це приховування реалізації. Скорочення доступу до приватних членів даних (деталі реалізації класу) дозволяє значно простіше змінити код пізніше. Якщо друг безпосередньо отримує доступ до приватних даних, будь-які зміни в полях даних про реалізацію (приватні дані) порушують код доступу до цих даних. Використання методів доступу в основному усуває це. Дуже важливо, я думаю.

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

Але навіть у C # є ключове слово з внутрішньою видимістю, а для деяких програм у Java є доступність пакету за замовчуванням . C ++ насправді наближається до ідеалу OOP, зводячи до мінімуму компроміс видимості в клас, конкретизуючи , який саме клас та лише інші класи можуть бачити в ньому.

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

Але тоді є InternalsVisibleTo атрибут (otherAssembly) , який діє як крос-збірка іншого механізм. Microsoft використовує це для збірок візуальних дизайнерів .

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

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

Стає простіше приховати речі, які вниз за течією не повинні бачити таким чином.