Функция удаления переменных и тп. Кто как делает?

[AndreyD]

Мучает вопрос по поводу удаления всех слушателей и переменных, которые уже не нужны.
Конкретная ситуация: Есть класс, экземпляр которого делает кучу слушателей и переменных. Когда пользователь понажимал вдоволь по кнопочкам в итоге нажимает кнопку закрыть, в этот момент у меня экземпляр класса удаляется со сцены и делается null.

Очень беспокоит всё содержимое того экземпляра, в том числе слушатели и переменные, что с ними?
Я для надёжности пытаюсь прикрутить функцию, которая будет чистить всё перед удалением со сцены и заnullением экземпляра, но всё какая-то лажа получается.

Поделитесь опытом, что вы делаете в таких ситуациях?

[DaFive]

Надо отписываться от всех событий и занулять ссылки перед удалением.
Можно написать свой эвентМенеджер, через который будете добавлять события чему-либо и через который будете отписывать от всех событий (к примеру функа removeAllListeners). Ну, ссылки не забыть удалить тоже.

[expl]

Надо отписываться от всех событий и занулять ссылки перед удалением.

Это не так. Например, если мы подписываемся на события ненужного (предполагаемого к сносу) объекта, то это его в памяти не задержит (главное чтобы он во время ожидания сноса их не слали проц тем самым не грузил). Подписка на себя самого тоже для GC не помеха.

Можно написать свой эвентМенеджер, через который будете добавлять события чему-либо и через который будете отписывать от всех событий (к примеру функа removeAllListeners). Ну, ссылки не забыть удалить тоже.

Для какого-то частного случая это будет работать. В общем случае это только усложнит код и увеличит сложность

[КорДум]

Я имплементирую всем таким классам интерфейс IDisposable (кастомный, естественно) с методом dispose(). Реализовываю удаление слушателей и уничтожение всего и вся именно в нем.

в этот момент у меня экземпляр класса удаляется со сцены и делается null.

А перед этим нужно вызвать dispose()

[AndreyD]

Такс расклад примерно понятен, теперь для гугла готов нормальный запрос, для изучения подробностей вышесказанного))

[Hidest]

Сообщение от КорДум

Я имплементирую всем таким классам интерфейс IDisposable (кастомный, естественно) с методом dispose(). Реализовываю удаление слушателей и уничтожение всего и вся именно в нем.

А перед этим нужно вызвать dispose()

Делаю один в один так же! В одном информационном поле находимся

[caseyryan]

Делаю один в один так же! В одном информационном поле находимся

+1. Тоже точно так же делаю
и интерфейс IDisposable и метод dispose()
плюс если у меня это дисплей объект, то он сам себя еще и удаляет из родителя

if (parent) parent.removeChild(this);

Так что в том месте, где вызыван метод dispose() на этом экземпляре достаточно только занулить ссылку на него после вызова

[Korchy]

Сообщение от caseyryan

+1. Тоже точно так же делаю

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

[TanaTiX]

сам себя еще и удаляет из родителя

Объект-камикадзе, забавно. Помню холивары на эту тему на форуме. Для вас сразу "отрезюмирую": объектами должны управлять родители, скажем "НЕТ!" суициду, убивать детей надо правильно.

[caseyryan]

Для вас сразу "отрезюмирую": объектами должны управлять родители, скажем "НЕТ!"

Еще один холивар разводите? )

Нет, я с этим не согласен. Если для объекта вызывается метод dispose(), как правило там, где он создан, значит объект должен быть уничтожен, это же очевидно. На кой его еще и удалять с дисплей листа там же? Лишняя заморочка. Не вижу тут логики. Объект может удалять сам себя, и это нормально.
А если метод dispose() оверрайдится, а удаление с дисплей листа происходит в суперклассе? Это избавляет от необходимости каждый раз писать код удаления. Я этот вопрос для себя уже давно отрезюмировал.

Вообще не очень понятно, почему бы адобовцам не сделать нормальный деструктор. Конечно сборщик мусора дело хорошее, но деструктор нужен, хотябы чтобы освободить объект от лишних ссылок.

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