Пришла мне однажды мысль, когда я маялся с тем чтобы один объект зависел от другого. Допустим A делает что-то, и это отражается в B, C и так далее.

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

Решил я сделать так, создать общий поток сообщений.
У меня есть супер объект, он содержит ВСЕ сообщения от всех объектов. И объекты могут посылать задачи только в него. И получать только из него. Захотел например A передать данные в B и C, он просто посылает сообщение:
А тем временем B и C:

И он не знает ни про какие B и C, а B и C не знают, что где-то надо искать A1, A2, A3, и подписываться на КАЖДЫЙ, B и C если надо им, просто обращаются/подписываются к суперхранителю сообщений, смотрят на все записанные сообщения, выбирают из них те, которые принадлежат им по id (очень удобно в игре, например, id звука или id столкновения пули), или точнее, они думают, что эти сообщения отправлены им, а потом обрабатывают. Если надо пихают результат туда же.

А ещё из одного потока событий, могут создаваться другие, например на msg0 самый главный поток подпишеися msg1 и будет выбирать сообщения клавиуатуры, и уже на него будут подписываться те, кто хочет иметь доступ к клавиатуре. Например, поток сообщений msg2 который каждые update() будет выбирать последний мессадж клавы и посылать в игру, в поток msg3, финальный поток событий, который может отправляться к msg4, который отправляет всё через http на сервак игры и на диск.

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

Чуется мне, что я изобрёл велосипед. Как он называется? Есть ли что-то подобное?

Как подметил Аригато, этот велосипед называется "Паттерны проектирования"

1. Это обыкновенный паттерн Pub/Sub. Или, если быть точнее, шина сообщений (event bus).
2. «[...] можно посмотреть историю сообщений и вернуться назад, и просчитать снова» — а это уже event sourcing.

Про код пули можно поподробнее

Мне это напомнило немного паттерн ecs(entity-component-system)