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

писал я это на с++ и возникла сразу проблема ввести какойто порядок остановки взаимодействия и освобождения памяти в такой системе, хотя бы чтобы избежать падений и утечек

в итоге после многих экспериментов я пришел к подходу который можно описать как обратные зависимости и событийное освобождение ресурсов

эта идея обратная классическому подходу при котором тот кто создал тот и удаляет, и реализована просто: зависимый объект подписывается на сообщении об удалении тех от которых он зависит
понятно дело что события слегка усложняют логику очистки, но этот подход и не предназначен для выделения памяти под мелочь типа string

зато:

— с таким подходом не нужно вообще соблюдать кактой порядок уничтожения объектов, можно удалять кого угодно когда угодно и где угодно, те кто от него зависят узнают об этом и вызовут самоуничтожение, а если и они имеют зависимости то рекурсивно будет освобождено всё что нужно
— самоубиваться не всегда и требуется, если зависимость критическая то да, а если нет, то связь просто обрывается и может быть восстановлена если подписаться на сообщение о том, что контрагент снова ожил, или ваще забить, отпал так отпал
— абсолютно пофиг на любые кольцевые зависимости, за ними даже не нужно следить, все будет очищено как нужно(это было важное достижение для системы в которой связи возникают непредсказуемо) и даже не нужен никакой сборщик мусора, можно даже самому на себя подписаться и это не беда ибо освобождение памяти происходит директивно: мы просто приказываем объекту умереть и он это немедленно исполняет предварителньо уведомив всех кому он нужен
— так как у нас с++, то пришлось ввести реестр чтобы не было проблемы вызова кода самоуничтожевшегося объекта, зато при желании это дает возможность отложенного освобождения памяти мертвых объектов — типа кеширования, т.е. избежание пересоздания объектов в случае если к ним часто подключаются и тут же быстро отключаются.
— т.е. тут есть аж 3 пути смерти и очистки — принудительный, по исчезновению подписчиков, и на основе стратегии кеширования, которые можно выбирать в зависимости от нужд
— не нужно считать никакие ссылки, подписка заменяет всё это




и спустя лет 10 уже тестирования этого могу сказать что проблем не обнаружено