2016-12-09 4 views
-1

Возможно ли это сразу же позвонить и отказаться от подписки на события в этом контексте? context_ используется для управления простой statemachine, которую мы запускаем и останавливаем по существу, создавая новую.C# Dispose(), отписаться от событий

class ClassA 
{ 

     StateContext context_; 

     void SomeMethod() 
     { 
     if(context_ != null) 
      context_.Dispose(); 

      context_ = new StateContext(); 

     } 

    class StateContext : IDisposable 
    { 
     SubClassA() 
     { 
      //Subscribe to an event 
     } 

     void Dispose() 
     { 
      //unsubscribe to an Event 
     } 
    } 

} 
+0

Нет, вы нарушаете договор с IDisposable. Нарушения контракта требуют дополнительного внимания и тяжелых комментариев. Пока класс не является общедоступным, вы с ним справитесь. –

+1

Если фактический код действительно похож на код примера, вы можете просто просто «Dispose» в «Unsubscribe», а не реализовывать «IDisposable» и по-прежнему иметь такое же поведение без необходимости спрашивать: «Мне разрешено создавать методы, которые выполняют мои требуемая логика " – SimpleVar

ответ

0

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

Обратите внимание, что термин «неуправляемый ресурс» имеет только минимальное отношение к термину «неуправляемый код» и что нормальными событиями из долгоживущих объектов являются неуправляемые ресурсы. Таким образом, хотя события не имеют никакого отношения к неуправляемому коду, совершенно правильно и правильно использовать IDisposable для их очистки. В самом деле, я бы предположил, что такая очистка должна считаться обязательной, если не существует каких-либо других средств для обеспечения очистки (например, события обрабатываются менеджером слабых событий или объект, чье событие подписано, не будет переживать абонента). Код WinForms часто неаккуратен, исходя из предположения, что издатели событий не ожидают подписчиков, но это не означает, что такая неряшливость должна считаться желательной.