Например:
public class Person
{
public Person()
{
}
~Person()
{
}
}
Когда я должен вручную создать деструктор? Когда вам нужно было создать деструктор?
Например:
public class Person
{
public Person()
{
}
~Person()
{
}
}
Когда я должен вручную создать деструктор? Когда вам нужно было создать деструктор?
Ответы:
ОБНОВЛЕНИЕ: Этот вопрос был темой моего блога в мае 2015 года . Спасибо за отличный вопрос! Смотрите в блоге длинный список лжи, которые люди обычно верят в финализацию.
Когда я должен вручную создать деструктор?
Почти никогда.
Обычно один создает деструктор только тогда, когда ваш класс держится за какой-то дорогой неуправляемый ресурс, который должен быть очищен, когда объект исчезает. Лучше использовать одноразовый шаблон, чтобы обеспечить очистку ресурса. Деструктор - это, по сути, гарантия того, что, если потребитель вашего объекта забудет его утилизировать, ресурс все равно будет очищен. (Может быть.)
Если вы делаете деструктор, будьте предельно осторожны и понимайте, как работает сборщик мусора . Деструкторы являются действительно странно :
Почти все, что обычно верно, верно для деструктора. Будьте очень, очень осторожны. Написание правильного деструктора очень сложно.
Когда вам нужно было создать деструктор?
При тестировании части компилятора, которая обрабатывает деструкторы. Мне никогда не нужно было делать это в рабочем коде. Я редко пишу объекты, которые манипулируют неуправляемыми ресурсами.
Он называется «финализатор», и вам обычно следует создавать его только для класса, состояние которого (например, поля) включает неуправляемые ресурсы (т. Е. Указатели на дескрипторы, полученные с помощью вызовов p / invoke). Однако в .NET 2.0 и более поздних версиях существует более эффективный способ очистки неуправляемых ресурсов: SafeHandle . Учитывая это, вам больше не нужно писать финализатор снова.
Он вам не нужен, если ваш класс не поддерживает неуправляемые ресурсы, такие как дескрипторы файлов Windows.
Он называется деструктором / финализатором и обычно создается при реализации шаблона Disposed.
Это запасное решение, когда пользователь вашего класса забывает вызвать Dispose, чтобы убедиться, что (в конечном итоге) ваши ресурсы будут освобождены, но у вас нет никаких гарантий относительно того, когда вызывается деструктор.
В этом вопросе переполнения стека принятый ответ правильно показывает, как реализовать шаблон удаления. Это необходимо только в том случае, если ваш класс содержит какие-либо неиспользованные ресурсы, которые не удастся очистить сборщику мусора.
Хорошей практикой является не реализовывать финализатор, не предоставляя пользователю класса возможность вручную удалить объект, чтобы сразу освободить ресурсы.
Если у вас есть неуправляемые ресурсы, и вы должны убедиться, что они будут очищены, когда ваш объект исчезнет. Хорошим примером могут быть COM-объекты или обработчики файлов.
Я использовал деструктор (только для целей отладки), чтобы посмотреть, удалялся ли объект из памяти в области видимости приложения WPF. Я был не уверен, действительно ли сборщик мусора удалял объект из памяти, и это был хороший способ проверить.
Деструкторы предоставляют неявный способ освобождения неуправляемых ресурсов, инкапсулированных в вашем классе, они вызываются, когда к нему обращается GC, и неявно вызывают метод Finalize базового класса. Если вы используете много неуправляемых ресурсов, лучше предоставить явный способ освобождения этих ресурсов через интерфейс IDisposable. См. Руководство по программированию на C #: http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx