Коли я повинен створити деструктор?

Наприклад:

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