Я знаю интерфейс IDisposable и использую его в .net, но есть вопрос, на мой взгляд, что если я пишу весь управляемый код, реализует ли интерфейс IDisposable смысл?
Я знаю, когда и как использовать Idisposible, но мой вопрос в том, что я пишу весь управляемый код, говорящий простой класс, ничего дорогостоящего в этом, поэтому, если я реализую IDisposable в этом классе и делаю некоторую очистку, например, освобождая некоторые глобальные значения, Имеет ли смысл?
Нет, вам может не понадобиться использовать интерфейс IDisposble. Тем не менее, он рекомендовал при определенных обстоятельствах (я могу добавить более поздние, как я помню:)):
У вас есть много объектов, и есть много перекрестных ссылок. Даже несмотря на то, что все это удалось, GC не сможет вернуть память из-за живых ссылок. У вас есть шанс (кроме написания финализатора), чтобы распутать ссылки и разбить ссылки так, как вы их прикрепили. Следовательно, вы помогаете GC восстановить память.
У вас есть потоки, которые открыты, пока объект класса не умрет. Несмотря на то, что такие реализации файлов/сетей и т.д. Управляются, они идут глубоко в ручную в режиме Win32. Следовательно, вы получаете возможность написать метод Dispose, где вы можете закрыть потоки. То же самое верно для объектов GDI и еще нескольких.
Вы пишете класс, который использует неуправляемые ресурсы, и вы хотите отправить свою сборку третьим лицам. Вам лучше использовать одноразовый шаблон, чтобы убедиться, что вы можете освободить ручки, чтобы избежать утечки.
Благодаря supercat для этого: ваш класс реализует множество обработчиков событий и подключает их к событиям. Объекты классов, которые выставляют события, такие как Form и т.д., Не будут освобождены GC, поскольку реализации, локальные для вашего класса (возможно), все еще подключены к этим событиям. Вы можете отцепить эти обработчики событий в Dispose; снова помогая GC.
Хм... Я не могу вспомнить больше прямо сейчас, но если класс является сложным по своему поведению, вам может потребоваться переосмыслить, почему вы не хотите реализовывать интерфейс IDisposable.
Правило: вам нужно реализовать IDisposable, если ваш тип имеет переменную-член, которая сама является IDisposable или если она неуправляема. GC не детерминирован в .NET и IDisposable дает вам детерминированный способ не возвращать память, а восстанавливать ресурсы. Поэтому, когда вызывается Dispose(), ваша память не сразу освобождается GC, но вы можете деинсталлировать очистку неуправляемых ресурсов (например, убедитесь, что соединения с базой данных закрыты, а на сервере не установлены максимальные соединения).
Если у вас есть ресурс, который необходимо восстановить (например, File), вы хотите иметь IDisposible, чтобы явно закрыть его и не дожидаться завершения GC.
Редко упоминаемый сценарий, где правильное использование iDisposable является критическим, - это объект с коротким сроком полезного использования, который получает события от долгоживущего объекта. Метод Dispose для такого объекта должен отменить подписку на его события. Если объект не отменяет подписку, он не будет иметь права на сбор мусора до тех пор, пока объект (ы), события которого он подписал, не будет допущен к сбору мусора; это может быть очень хорошо.
Например, некоторые типы перечислителей должны подписываться на сообщения об изменении объекта. Было бы вполне правдоподобно, чтобы многие тысячи таких счетчиков были созданы во время выполнения долговременной программы. Если такие счетчики не были отписаны, они могут эффективно блокировать систему, даже если они никогда не используют какие-либо ресурсы, кроме управляемой памяти.
Заметьте, кстати, что, несмотря на важность утилизации такого объекта, добавление финализатора для обеспечения такого удаления было бы бесполезным. Если издатель событий вышел из сферы действия, попытка отказаться от подписки с одного из его событий была бы в лучшем случае бесполезной и, возможно, опасной. Поскольку абонент событий не может выйти из сферы действия, если издатели всех событий, которые он получил, также вышли из сферы действия, финализатор будет вызван только после того, как ему нечего было делать.
Да, даже если у вас нет управляемых ресурсов, IDisposable может быть полезен. Зачем? Поскольку метод Dispose можно использовать для reset ссылок на объекты обратно на null.
Обратите внимание, что это само по себе еще не освобождает никаких ресурсов, поскольку сбор мусора является недетерминированным (т.е. он обычно не запускается в любой момент по вашему выбору), НО он разрывает ссылки (ссылки) между объектами, что делает более вероятным, что некоторые объекты будут иметь право на сбор мусора на следующем запуске GC.
Есть ли смысл?
Нет, сделайте свой объект доступным только в том случае, если его создать очень дорого.