просто когда ты один (или людей мало) все это не так очевидно в плане профита

Ребята, у меня такой вопрос. Есть в разработке event-driven подход - это когда мы при наступлении события, отправляем некое сообщение, которое получаю все те, кто на него подписан. Хорошо, а как бы выглядел ООП код, без такого подхода - можно пример. То есть, скажем, например у нас  пересеклись два объекта и мы что то хотим сделать. Верно я понимаю, что в слуае не event-driven подхода, мы просто должы будем в функцию пересечения передавать некоторые объекты, с которомы что-то должно произойти?

То есть вот, такой код в event-driven:

void some_call(...)
{
   if (...)
       emit event intersected
}

entity_1::intersected()
   to do something

e.t.c

Как бы код выше выглядел без ED подхода?

Странный вопрос, а что по твоему происходит когда вызывается emit? И что ты подразумеваешь под ООП кодом?

Ну когда emit - метод интерфейса, который entity_1 реализует. И уже работает внутри себя.

Таким образом, some_call ничего не знает про entity\

но знает только про интерфейс подписчика

вот, я так понимаю что это event driven

Ну типа берем лист, кладем туда подписчиков. Те подписываем их. Далее вызывающая функция проходится по всем подписчиками вызываем туже самую функцию. Это как пример.
Паттерн Медиатор обычно называется. https://refactoring.guru/ru/design-patterns/mediator

Это будет не event-driven решение?

Мне именно пример не event-driven нужен

А фиг знает что ты под event-driven имеешь ввиду. Оч общее понятие.

Ну можешь функции по порядку вызывать, вот тебе и не event-driven

Да вот я думаю, что не ивент драйвен, это когда мы в
void some_call(...)
{
   if (...)
       emit event intersected
}

Работаем со всем entity - раскрывая их интерфейс

то есть не с интерфейсом слушателя работаем, а просто с объектом

вот этот момент я и пытаюсь уточнить - как бы это было без event driven

так же (emit внутри держит рефы на всех листенеров например).

Разница в том что при полноценном ED не обязательно держать все в одном процессе + не обязательно ждать пока они закончат

+ не обязательно ждать пока они закончат

Это про асинхронность?

+ не обязательно ждать пока они закончат

это уже больше про message passing, ED спокойно себя чувствует без всего этого (просто львиную долю профита от подхода теряем)

ивенты это способ уведомить третью сторону о чем-то не знаю о том кто хочет быть уведомленным. Мол "чет произошло, мне не важно вообще обработает это сообщение кто-то или нет".

"без ивентов" мы просто должны знать кто должен обрабатывать сообщение в целом) но это можно обойти сделав абстрактного ресипиента которы внутри себя все разруливает. Но это те же ивенты

А типа не в ED - все держится в одном процессе? А можешь показать как?