Здравствуйте, Hоmunculus, Вы писали:
H>Как считаете — friend это костыль для кривой архитектуры или норм?
Да, считаю подобные заморачивания лишним пложением сущностей. Вообще использую структуры, чтобы не писать
public.
А если хочется скрыть члены класса, делаю это через наследование.
И опять же все public, на случай дебага удобно бывает временно в лог закинуть что-то из кишок не городя дополнительных членов класса для этого.
Разделение на интерфейс и реализацию должно натурально получаться.
Thing.h:
#ifndef Thing_H
#define Thing_H
#include "Thing_inline.h"
struct Thing:Thing_private{
//публичные члены
};
#include "Thing_inline.h"
#endif
Thing_inline.h:
#ifndef Thing_private
#define Thing_private
#include "Thing.h"
struct Thing_private{
//приватные члены
};
#else
#ifndef Thing_inline
#define Thing_inline
//А сюда инлайн функции, чтоб тоже глаза не мозолили в основном хидере
#endif
Здравствуйте, Hоmunculus, Вы писали:
H>Как считаете — friend это костыль для кривой архитектуры или норм?
Но ты ведь понимаешь, что код со всегда открытыми модификаторами доступа будет работать точно так же как с закрытыми, защищёнными и дружественными. То есть если я приду и сотру все твои модификаторы доступа в готовой программе назначив все члены открытыми, то ничего не изменится.
По сути всё это синтаксический сахар для стадии компиляции программы. Это нужно тебе как программисту, а не компьютеру. А теперь задумайся, действительно ли нужны модификаторы доступа, зачем так усложнять? Их же надо ещё продумывать, тратить на это усилия.
Говорят почему что-то сделано так, а не иначе написано в книге
"Дизайн и эволюция языка C++. Страуструп Бьерн". Ну я не знаю, не читал и не осуждаю. А нужно ли ООП? А нужно ли то? А нужно ли это?
Я смотрю сейчас модно стало спрашивать всё у нейронок. Это только динозавры пишут сами.
https://www.google.com/ai
Как считаете — friend это костыль для кривой архитектуры или норм.
Когда friend — это нормально (обоснованное архитектурное решение)
Перегрузка операторов ввода/вывода (<< и >>): Это самый распространенный пример. Операторы должны иметь доступ к внутренним данным класса, но не являются его членами (они принимают поток в качестве левого операнда), поэтому объявление их friend — стандартная практика.
Тесная взаимосвязь между классами (сильная связность): Иногда набор классов или функций представляет собой единый логический модуль, который просто разбит на части по техническим причинам (например, управление временем жизни объектов). В этом случае предоставление доступа через friend позволяет сохранить инкапсуляцию внутри модуля, не выставляя внутренние детали во внешний публичный интерфейс.
Вспомогательные функции, не требующие публичного API: Для некоторых служебных функций, которым нужен доступ к внутренним данным, но которые не должны быть частью публичного интерфейса класса.
Оптимизация производительности: В некоторых случаях friend-функции могут обеспечить более эффективный доступ к данным, чем использование публичных геттеров/сеттеров, что может быть критично для высокопроизводительных систем.
Когда friend — это "костыль" (признак кривой архитектуры)
Нарушение инкапсуляции без необходимости: Если friend используется просто для удобства доступа к приватным данным из произвольного места программы, когда можно обойтись публичным интерфейсом, это нарушает принципы ООП и усложняет поддержку кода.
Свидетельство плохого разбиения на классы: Чрезмерное использование friend может указывать на то, что логика, которая должна находиться внутри одного класса (или родственных классов), неоправданно разнесена по разным частям системы.
Усложнение отладки и поддержки: Большое количество "дружественных" функций или классов увеличивает зависимости, делая код менее модульным и более трудным для понимания и отладки.
Резюме: friend — это мощный инструмент, который дает разработчику возможность сознательно управлять доступом к приватным членам. Использовать его нужно осознанно и только тогда, когда это действительно оправдано дизайном, а не как обходной путь для решения проблем, вызванных поспешным проектированием. При правильном применении он помогает создать более чистую и эффективную архитектуру.
