C # абстрактный метод Dispose

Вы должны следовать общепринятой схеме реализации Dispose. Создание Dispose() виртуальным считается плохой практикой, потому что традиционный шаблон подчеркивает повторное использование кода в «управляемой очистке» (клиент API, вызывающий Dispose() напрямую или через using) и «неуправляемой очистке» (вызов финализатора GC). Напомним, узор такой:

public class Base
{
    ~Base()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // so that Dispose(false) isn't called later
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
             // Dispose all owned managed objects
        }

        // Release unmanaged resources
    }
}

Ключевым моментом здесь является то, что нет дублирования между финализатором и Dispose для неуправляемой очистки, и тем не менее любой производный класс может расширять как управляемую, так и неуправляемую очистку.

В вашем случае вам следует сделать следующее:

protected abstract void Dispose(bool disposing)

а все остальное оставьте как есть. Даже это имеет сомнительную ценность, поскольку сейчас вы заставляете свои производные классы реализовывать Dispose - и как узнать, что всем это нужно? Если вашему базовому классу нечего удалять, но большинство производных классов, вероятно, справляются с этим (возможно, за некоторыми исключениями), тогда просто предоставьте пустую реализацию. Это то, что делает System.IO.Stream (сам по себе абстрактный), поэтому есть прецедент.

В основном предупреждении предлагается реализовать шаблон удаления в вашем классе.

public abstract class ConnectionAccessor : IDisposable
{
    ~ConnectionAccessor()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
    }
}

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

См. эту запись в блоге Джо Даффи, который объясняет, когда вам может понадобиться финализатор, а когда нет, и как правильно реализовать шаблон Dispose в любом случае.
Подводя итоги сообщения в блоге Джо, если вы не делаете что-то довольно низкоуровневое, имеющее дело с неуправляемой памятью, вы не должен реализовывать финализатор. Как правило, если ваш класс содержит только ссылки на управляемые типы, которые сами реализуют IDisposable, вам не нужен финализатор (но следует реализовать IDisposable и удалить эти ресурсы). Если вы выделяете неуправляемые ресурсы непосредственно из своего кода (PInvoke?), И эти ресурсы необходимо освободить, он вам понадобится. Производный класс всегда может добавить финализатор, если он действительно нужен, но принуждение всех производных классов иметь финализатор путем помещения его в базовый класс приводит к тому, что на все производные классы влияет снижение производительности финализуемых объектов, когда эти накладные расходы могут не быть необходимо.

Хотя это действительно похоже на придирки, совет действителен. Вы уже указываете, что ожидаете, что любые подтипы ConnectionAccessor будут иметь что-то, что им необходимо удалить. Поэтому кажется лучше убедиться, что надлежащая очистка выполняется (с точки зрения вызова GC.SuppressFinalize) базовым классом, а не полагаться на каждый подтип.

Я использую шаблон удаления, упомянутый в книге Брюса Вагнерса Эффективный C # который в основном:

public class BaseClass : IDisposable
{
    private bool _disposed = false;
    ~BaseClass()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            //release managed resources
        }

        //release unmanaged resources

        _disposed = true;
    }
}

public void Derived : BaseClass
{
    private bool _disposed = false;

    protected override void Dispose(bool disposing)
    {
        if (_disposed) 
            return;

        if (disposing)
        {
            //release managed resources
        }

        //release unmanaged resources

        base.Dispose(disposing);
        _disposed = true;
    }

Однако предупреждение интересно. Эрик Липперт, один из разработчиков C #, писал в блоге, почему сообщения об ошибках должны быть «диагностическими, но не предписывающими: описывать проблему, а не решение». Прочтите здесь .