Дружественные классы в C++

[Huseyn AX]

Если создать взаимно дружественные классы, можно ли их ограничить так: например создали класс A и B, и внутри A мы сделали дружественными только некоторые функции-элементы от B, а у B внутри мы сделали дружественными только некоторые функции-элементы от A.Какие то проблемы будут ?

[Valick]

На сколько я понял при объявлении дружественным целый класс, доступны будут все функции. Елинственное чего я не понял, так это вообще назначение этих самых друзей. В С++ точно есть ООП?

[Алексей1153]

Huseyn AX, можно отдельные функции задружить:

#include <iostream>

class A
{
public:
    void f1();
};

class B
{
    friend void A::f1();
public:
    void f1()
    {
    }
private:
    void f2()
    {
    }
};

void A::f1()
{
    B{}.f1();
    
    //доступ к приватному методу класса B
    B{}.f2();
}

int main()
{
}

Valick, а какая связь ООП с доступом к полям и методам? ООП можно и на чистом Си, и на ассемблере замутить

[Алексей1153]

Сообщение от Valick

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

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

[Valick]

Сообщение от Алексей1153

Valick, а какая связь ООП с доступом к полям и методам?

Без инкапсуляции нет ООП.

Сообщение от Алексей1153

в подавляющем большинстве случаев причина - ошибка проектирования.

Это где-то описано? А ещё интересуют случаи которые не в большинстве. Есть ли такие обстоятельства при которых невозможно написать код без использования дружественных функций?

Сообщение от Алексей1153

Но потом, в спокойной обстановке, неплохо бы произвести рефакторинг

Конечно, плохой код мешал вашей работе. Почему же вы писали его? Пытались
поскорее решить задачу? Торопились? Возможно. А может быть, вам казалось,
что у вас нет времени качественно выполнить свою работу; что ваше начальство
будет недовольно, если вы потратите время на чистку своего кода. А может, вы
устали работать над программой и вам хотелось поскорее избавиться от нее. А мо-
жет, вы посмотрели на список запланированных изменений и поняли, что вам
необходимо поскорее «прикрутить» этот модуль, чтобы перейти к следующему.
Такое бывало с каждым.
Каждый из нас смотрел на тот хаос, который он только что сотворил, и решал
оставить его на завтра. Каждый с облегчением видел, что бестолковая программа
работает, и решал, что рабочая мешанина — лучше, чем ничего. Каждый *обещал
себе вернуться и почистить код… потом. Конечно, в те дни мы еще не знали закон
Леблана: потом равносильно никогда.
Роберт Мартин - Чистый код

[Алексей1153]

Сообщение от Valick

Без инкапсуляции нет ООП.

в ассемблере и Си нет никакой инкапсуляции, но ООП там применять возможно. Инкапсуляция может быть просто правилом, хотя и не поддерживаемым компилятором

Сообщение от Valick

Это где-то описано

кхм... А как же абзацем выше утверждение про необходимость инкапсуляции?
Может, и описано где-то. У меня это следует из опыта

Сообщение от Valick

А ещё интересуют случаи которые не в большинстве

например, локальный или приватный класс-помощник в другом классе

Сообщение от Valick

плохой код мешал вашей работе. Почему же вы писали его?

у меня так бывало в основном из-за отсутствия нужных знаний на момент написания первого варианта кода А через год туда смотришь - мамамия! А кто это сдееелал!

[Valick]

Сообщение от Алексей1153

Инкапсуляция может быть просто правилом, хотя и не поддерживаемым компилятором

сама по себе сущность дружественной функции - это нарушение этого правила

Сообщение от Алексей1153

А через год туда смотришь - мамамия!

а в коде сплошные классы "помошники"

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