Осуществление “конца” звонит каждый раз, когда существует соответствующий вызов “запуска”

Мы сделали почти в точности то, что вы предлагаете, как способ добавления ведения журнала трассировки методов в наши приложения. Beats, что нужно сделать 2 журнала регистрации, один для входа и один для выхода.

Я немного прокомментировал здесь некоторые ответы о том, что IDisposable есть и нет, но я повторю, что IDisposable должен включать детерминированную очистку, но не гарантирует детерминированную очистку. то есть его вызов не гарантируется, а лишь отчасти гарантируется в паре с с использованием блока .

// despite being IDisposable, Dispose() isn't guaranteed.
Jumper j = new Jumper();

Я не буду комментировать ваше использование с помощью , потому что Эрик Липперт справился с этим гораздо лучше.

Если у вас есть класс IDisposable, не требующий финализатора, я видел шаблон для определения, когда люди забывают вызвать Dispose () , заключается в добавлении финализатора, который условно компилируется в сборках DEBUG, чтобы вы можете регистрировать что-то всякий раз, когда вызывается ваш финализатор.

Реалистичный пример - это класс, который каким-то особым образом инкапсулирует запись в файл. Поскольку MyWriter содержит ссылку на FileStream , который также является IDisposable , мы также должны реализовать IDisposable из соображений вежливости.

public sealed class MyWriter : IDisposable
{
    private System.IO.FileStream _fileStream;
    private bool _isDisposed;

    public MyWriter(string path)
    {
        _fileStream = System.IO.File.Create(path);
    }

#if DEBUG
    ~MyWriter() // Finalizer for DEBUG builds only
    {
        Dispose(false);
    }
#endif

    public void Close()
    {
        ((IDisposable)this).Dispose();
    }

    private void Dispose(bool disposing)
    {
        if (disposing && !_isDisposed)
        {
            // called from IDisposable.Dispose()
            if (_fileStream != null)
                _fileStream.Dispose();

            _isDisposed = true;
        }
        else
        {
            // called from finalizer in a DEBUG build.
            // Log so a developer can fix.
            Console.WriteLine("MyWriter failed to be disposed");
        }
    }

    void IDisposable.Dispose()
    {
        Dispose(true);
#if DEBUG
        GC.SuppressFinalize(this);
#endif
    }

}

Ой. Это довольно сложно, но именно этого люди ожидают, когда видят IDisposable.

Класс пока даже ничего не делает, кроме открытия файла, но это то, что вы получаете с IDisposable , а ведение журнала чрезвычайно упрощено.

    public void WriteFoo(string comment)
    {
        if (_isDisposed)
            throw new ObjectDisposedException("MyWriter");

        // logic omitted
    }

Финализаторы дороги, а MyWriter выше не требует финализатора, поэтому нет смысла добавлять его вне сборок DEBUG.

1. Я не думаю, что вы хотите, чтобы эти методы были статичными.
2. Вам нужно проверить при удалении, был ли уже вызван переход к концу.
3. Что произойдет, если я снова вызову начало прыжка?

Вы можете использовать счетчик ссылок или флаг, чтобы отслеживать состояние «прыжка». Некоторые люди скажут, что IDisposable предназначен только для неуправляемых ресурсов, но я думаю, что это нормально. В противном случае вы должны сделать начало и конец прыжка частными и использовать деструктор для работы с конструктором.

class Jumper
{
    public Jumper() {   Jumper.StartJumping(); }
    public ~Jumper() {  Jumper.EndJumping(); }

    private void StartJumping() {...}
    public void EndJumping() {...}
}

Будет ли полезен абстрактный базовый класс? Метод в базовом классе может вызвать StartJumping (), реализацию абстрактного метода, который будут реализовывать дочерние классы, а затем вызвать EndJumping ().

Альтернативный подход, который будет работать при некоторых обстоятельствах (т.е. когда все действия могут происходить в конце), заключался бы в создании серии классов с плавным интерфейсом и некоторым финальным методом Execute ().

var sequence = StartJumping().Then(some_other_method).Then(some_third_method);
// forgot to do EndJumping()
sequence.Execute();

Execute () может возвращаться вниз по цепочке и обеспечивать соблюдение любых правил (или вы можете построить последовательность закрытия по мере построения последовательности открытия).

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

Мне нравится этот стиль, и я часто использую его, когда хочу гарантировать некоторое поведение разрыва: часто его читать намного проще, чем попытаться окончательно. Я не думаю, что вам следует беспокоиться об объявлении и названии ссылки j, но я считаю, что вам следует избегать вызова метода EndJumping дважды, вы должны проверить, не был ли он уже удален. И что касается вашего примечания к неуправляемому коду: это финализатор, который обычно реализуется для этого (хотя обычно вызываются Dispose и SuppressFinalize, чтобы освободить ресурсы раньше).

Джефф,

то, что вы пытаетесь достичь, обычно называют аспектно-ориентированным программированием (AOP ). Программирование с использованием парадигм АОП на C # непросто - и надежно ... пока что. Некоторые возможности, встроенные непосредственно в среду CLR и .NET, делают возможным использование АОП в определенных узких случаях. Например, когда вы наследуете класс от ContextBoundObject , вы можете использовать ContextAttribute для внедрения логики до / после вызовов методов в экземпляре CBO. Вы можете увидеть примеры того, как это делается здесь.

Создание класса CBO раздражает и ограничивает - и есть еще одна альтернатива. Вы можете использовать такой инструмент, как PostSharp, для применения АОП к любому классу C #. PostSharp гораздо более гибок, чем CBO, потому что он по существу переписывает ваш код IL на этапе посткомпиляции . Хотя это может показаться немного пугающим, оно очень мощное, потому что позволяет вплетать код практически любым способом, который вы можете себе представить.Вот пример PostSharp, созданный на основе вашего сценария использования:

using PostSharp.Aspects;

[Serializable]
public sealed class JumperAttribute : OnMethodBoundaryAspect
{
  public override void OnEntry(MethodExecutionArgs args) 
  { 
    Jumper.StartJumping();
  }     

  public override void OnExit(MethodExecutionArgs args) 
  { 
    Jumper.EndJumping(); 
  }
}

class SomeClass
{
  [Jumper()]
  public bool SomeFunction()  // StartJumping *magically* called...          
  {
    // do some code...         

  } // EndJumping *magically* called...
}

PostSharp достигает магии , переписывая скомпилированный код IL, чтобы включить инструкции для выполнения кода, который вы определили в JumperAttribute class ' OnEntry и OnExit методы.

Мне неясно, является ли в вашем случае PostSharp / AOP лучшей альтернативой, чем "перепрофилирование" оператора using. Я склонен согласиться с @Eric Lippert, что ключевое слово using запутывает важную семантику вашего кода и накладывает побочные эффекты и семантическое ментирование на символ } в конце блока using, что неожиданно . Но чем это отличается от применения атрибутов АОП к вашему коду? Они также скрывают важную семантику за декларативным синтаксисом ... но это своего рода суть АОП.

Один момент, в котором я полностью согласен с Эриком, заключается в том, что изменение вашего кода, чтобы избежать такого глобального состояния (когда это возможно), вероятно, является лучшим вариантом. Это не только позволяет избежать проблемы обеспечения правильного использования, но также может помочь избежать проблем с многопоточностью в будущем, к которым глобальное состояние очень восприимчиво.

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

public static void Jump(Action<Jumper> jumpAction)
{
    StartJumping();
    Jumper j = new Jumper();
    jumpAction(j);
    EndJumping();
}

На самом деле я не считаю это злоупотреблением использованием ; Я использую эту идиому в разных контекстах, и у меня никогда не было проблем ... особенно с учетом того, что с использованием - всего лишь синтаксический сахар. Один из способов я использую его для установки глобального флага в одной из сторонних библиотек, которые я использую, чтобы изменение отменялось при завершении операций:

class WithLocale : IDisposable {
    Locale old;
    public WithLocale(Locale x) { old = ThirdParty.Locale; ThirdParty.Locale = x }
    public void Dispose() { ThirdParty.Locale = old }
}

Обратите внимание, что вам не нужно назначать переменную в с помощью пункт. Этого достаточно:

using(new WithLocale("jp")) {
    ...
}

Я немного скучаю по идиоме RAII C ++ здесь, где деструктор вызывается всегда. с использованием , я думаю, ближе всего к C #.

С шаблон использования Я могу просто использовать команду grep (? , чтобы найти все места, где могут быть проблемы.