Господа, меня вот какой "архитектурный" вопрос волнует.. Предположим есть несколько объектов

(не имеющие наследственной связи), которые должны как-то общаться между собой (например иметь ссылки друг на друга, или просто доступ к чужим данным, не суть важно).
Очевидно что в этом случае мы можем пойти как минимум 2мя путями:
1) Объявить некий публичный интерфейс к нужным данным.
2) Объявить некий приватный интерфейс и тупо начать френдить.

Оба варианта как по мне тухлые:
1 - создаёт опасность того, что этим интерфейсом воспользуется тот, кто им воспользоваться не должен.
2 - создаёт прям-таки железобетонные связи между классами, которые потом проблематично отслеживать и модерировать.
Ну и френды считаются мувитоном и признаком хреновой архитектуры, насколько я понимаю.

Собственно существует ли какая-то хитрость до которой я не догоняю, или проблема на самом деле надуманна?

Френды , это когда всё уже придумано до Вас, а переписывать не хочется или просто дорого )))

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

Dependency Injection?

1) почему это "опасность"? если интерфейс публичный то опасности быть не должно по определению Второй вариант ужасный как раз

Ну как же.. Если у нас есть некий публичное поле, да или даже геттер - всегда есть опасность использования его не по назначению.. Предположим, если геттер не константный, к неким внутренним данным объекта будет доступ у кого угодно помимо того объекта для которого он реально задумывался.. Т.е. есть опасность что на этот геттер кто-то потом ещё завяжется (чего по идеи не задумывалось).

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

Уже читал про passkey?

https://youtu.be/MdtYi0vvct0

1) проблема надуманна

Х.х. и в продакшн?

Тем более

Что тем более, вы просто пишете "как нибудь" без задней мысли и думания о последствиях?

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

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

Как насчёт полноценного (асинхронного?) обмена сообщениями между этими объектами? С сериализацией, диспатчингом сообщений, идентификаторами и тд?