C++ как правильно наследовать дружбу...

А ты уверен, что Ccc появится? Может, не мучать моск и зафрейндить оба класса?

Вот блин…

Написал, и сразу понял… Надо Renderer сделать френдом UI и добавить в оный Renderer аксессоры для добывания internal1 и interlal2

Но раз кто-то стал за этой темой следить, то не буду удалять… Может и другие мысли будут.

А для рендерера точно наследование будет лучшим решением? Может лучше включать его экземпляр как метод?

https://youtu.be/motLOioLJfg?list=PLj7_jxdAn3pY8wrEqutjNWulrPU11kgCk&t=579

А ты уверен, что Ccc появится? Может, не мучать моск и зафрейндить оба класса?

Не уверен… Но как-то очень не аккуратно получается… Не приносит чувства удовлетворения…

А для рендерера точно наследование будет лучшим решением?

Весьма вероятно что нет. Но так уже сделано…

почему не сделать Renderer наследником UI? то есть UI сделать базовым классом

ведь UI это сферический интерфейс в вакууме, интерфейс как идея, а Renderer - его бренное воплощение, получается

а уже от Renderer наследовать отрисовщиков на конкретных библиотеках

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

Можно воспользоваться одной из следующих идиом:

• PIMPL
• pass key
• attorney-client

Можно сделать внутренний класс Renderer::Interface, от которого наследовать AaaRenderer и BbbRenderer. Внутренний класс имеет доступ ко всем приватным членам внешнего, поэтому его можно использовать как интерфейс.

мост

Ссылка с «pass key» ведет туда же куда и c «PIMPL»

Прошу прощения, ошибся при вставке. Вот оригинальная ссылка, но это не особо принципиально, т.к. гуглится легко в нескольких вариантах.

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

Не надо. Renderer должен предоставлять API достаточное для рисования чего угодно.

Френды нужны для юнит тестов и свободных операторов. Если это не твой случай, то значит архитектура спроектированна неправильно. Её нужно переделывать.

класс UI который отвечает за интерфейс, его логику

Это тоже нужно разделить на две части.

Вроде выглядит как классическое (ну почти классическое вьюхи 2) MVVM. UI (Model по факту, где логика), View (у тебя их 2 на разных движках AaaRenderer и BbbRenderer) и ViewModel которая прослойка между Model и View (у тебя это рендер). Посмотри как люди делают на других языках такое, особенно часто это на WPF/Avalonia и шарпе. На плюсах почти то же самое, только с поправкой на то что это плюсы.

zx_gamer вон дело пишет, если всё правильно делать, то можно спокойно хоть 100 рендеров приделать.

Фак, какая же теперь всратая разметка…

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

Не надо. Renderer должен предоставлять API достаточное для рисования чего угодно.

Нет, ну ты чо, с целью дьявольского смеха же. У Руки Ыгееук Херба Саттера аж четыре способа, специально подобрано чтоб: френд, дефайн, р-каст, определение шаблонного метода.

//дьявольский смех тут

Если друг оказался вдруг
И не друг и не враг, а так…

Мне всегда казалось что дружба это косяк проектирования архитектуры.

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