.NET
C#
ООП
Проектирование и рефакторинг
17 ноября 2015

Самая простая и надежная реализация шаблона проектирования Dispose


Казалось бы, данный шаблон не просто прост, а очень прост, подробно разобран не в одной известной книге.

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

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

Предусловия


Никакого смешения управляемых и неуправляемых ресурсов


Я никогда не реализую сам и не советую коллегам использовать владение управляемыми и неуправляемыми ресурсами в одном классе.

Таким образом, один класс может:
  • Не владеть ресурсами вообще
  • Владеть одним неуправляемым ресурсом, то есть просто конвертировать его в управляемый
  • Владеть одним или многими управляемыми ресурсами

Наследование реализаций нежелательно


Я не использую наследование от классов без крайней необходимости, предлагаемая реализация предполагает в качестве объекта-владельца ресурсов экземпляр запечатанного класса.
Это не значит, что ее нельзя модифицировать для поддержки наследования.

Обертки для неуправляемых ресурсов реализуется с помощью Janitor.Fody


Обновление: в комментариях совершенно справедливо указано, что с этой целью лучше использовать классы, унаследованные от CriticalFinalizerObject и SafeHandle.

То, чем пользовался я
Этот плагин к Fody — бесплатному инструменту модификации кода сборок после компиляции — позволит не выписывать вручную тысячу и одну деталь реализации, необходимой для корректного освобождения ресурсов.
Ваш код (пример из документации):
public class Sample : IDisposable
{
    IntPtr handle;

    public Sample()
    {
        handle = new IntPtr();
    }

    public void Method()
    {
        //Some code
    }

    public void Dispose()
    {
        //must be empty
    }

    void DisposeUnmanaged()
    {
        CloseHandle(handle);
        handle = IntPtr.Zero;
    }

    [DllImport("kernel32.dll", SetLastError=true)]
    static extern bool CloseHandle(IntPtr hObject);
}

Результат постобработки:
public class Sample : IDisposable
{
    IntPtr handle;
    volatile int disposeSignaled;
    bool disposed;

    public Sample()
    {
        handle = new IntPtr();
    }

    void DisposeUnmanaged()
    {
        CloseHandle(handle);
        handle = IntPtr.Zero;
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern Boolean CloseHandle(IntPtr handle);

    public void Method()
    {
        ThrowIfDisposed();
        //Some code
    }

    void ThrowIfDisposed()
    {
        if (disposed)
        {
            throw new ObjectDisposedException("TemplateClass");
        }
    }

    public void Dispose()
    {
        if (Interlocked.Exchange(ref disposeSignaled, 1) != 0)
        {
            return;
        }
        DisposeUnmanaged();
        GC.SuppressFinalize(this);
        disposed = true;
    }


    ~Sample()
    {
        Dispose();
    }
}


Теперь можно перейти к самому распространенному случаю, ради которого и была написана эта статья.

Реализация шаблона проектирования Dispose для управляемых ресурсов


Подготовка


Для начала нам потребуется класс CompositeDisposable из библиотеки Reactive Extensions.
К нему необходимо дописать небольшой метод расширения:
public static void Add(this CompositeDisposable litetime, Action action)
{
    lifetime.Add(Disposable.Create(action));
}

Добавление поля, отвечающего за очистку


private readonly CompositeDisposable lifetime = new CompositeDisposable();

Реализация метода Dispose


public void Dispose()
{
    lifetime.Dispose();
}

Больше ничего и никогда в этот метод добавлять не нужно.

Очистка явно конструируемых ресурсов


Достаточно просто добавить простейший код прямо в место выделения ресурса.
Было:
myOwnResourceField = new Resource();

// И где-то при очистке
if (myOwnResourceField != null)
{
    myOwnResourceField.Dispose();
    myOwnResourceField = null;
}

Стало:
lifetime.Add(myOwnedResourceField = new Resource());


Отписка от событий


Было:
sender.Event += Handler;

// И где-то при очистке
sender.Event -= Handler

Стало:
sender.Event += Handler;
lifetime.Add(() => sender.Event -= Handler);


Отписка от IObservable


Было:
subscription = observable.Subscribe(Handler);

// И где-то при очистке
if (subscription != null)
{
    subscription.Dispose();
    subscription = null;
}

Стало:
lifetime.Add(observable.Subscribe(Handler));


Выполнение произвольных действий при очистке


CreateAction();
lifetime.Add(() => DisposeAction());


Проверка состояния объекта


if (lifetime.IsDisposed)


Выводы


Предлагаемый способ:
  • универсален: гарантированно покрываются любые управляемые ресурсы, даже такие как «при очистке выполните следующий код»
  • выразителен: дополнительный код невелик по объему
  • привычен: используется обыкновенный класс из очень популярной библиотеки, который, вдобавок, при необходимости несложно написать и самостоятельно
  • прозрачен: код очистки каждого ресурса расположен вплотную к коду захвата, большинство потенциальных утечек будут сразу замечены при рецензировании
  • ухудшает производительность: добавляет «memory traffic» за счет создания новых объектов
  • не влияет на безопасность использования уже «мертвого» объекта: собственные ресурсы очистятся только однажды, но любые проверки с выбросом ObjectDisposedException надо делать вручную

Буду рад, если описанный способ пригодится читателям.
+13
16,6k 95
Комментарии 13
Похожие публикации
Популярное за сутки