Як запобігти поширенню IDisposable на всі ваші заняття?

Почніть з цих простих занять ...

Скажімо, у мене простий набір таких класів:

class Bus
{
    Driver busDriver = new Driver();
}

class Driver
{
    Shoe[] shoes = { new Shoe(), new Shoe() };
}

class Shoe
{
    Shoelace lace = new Shoelace();
}

class Shoelace
{
    bool tied = false;
}

A Busмає a Driver, Driverмає два Shoes, кожен Shoeмає a Shoelace. Все дуже нерозумно.

Додайте об’єкт, який не використовується, в Shoelace

Пізніше я вирішую, що деяка операція над програмою Shoelaceможе бути багатопотоковою, тому я додаю EventWaitHandleпотоки для спілкування з ними. Отже, Shoelaceтепер виглядає так:

class Shoelace
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;
    // ... other stuff ..
}

Реалізуйте IDisposable на шнурці

Але тепер FxCop Microsoft поскаржиться: "Впровадьте IDisposable на" Shoelace ", оскільки він створює членів таких типів IDisposable:" EventWaitHandle "."

Гаразд, я впроваджую IDisposableдалі, Shoelaceі мій класний маленький клас стає цим жахливим безладом:

class Shoelace : IDisposable
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;
    private bool disposed = false;

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

    ~Shoelace()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!this.disposed)
        {
            if (disposing)
            {
                if (waitHandle != null)
                {
                    waitHandle.Close();
                    waitHandle = null;
                }
            }
            // No unmanaged resources to release otherwise they'd go here.
        }
        disposed = true;
    }
}

Або (як наголошують коментатори), оскільки Shoelaceсам по собі не має керованих ресурсів, я міг би скористатися більш простою реалізацією розпорядження, не потребуючи Dispose(bool)і Destructor:

class Shoelace : IDisposable
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;

    public void Dispose()
    {
        if (waitHandle != null)
        {
            waitHandle.Close();
            waitHandle = null;
        }
        GC.SuppressFinalize(this);
    }
}

Дивіться з жахом, як розповсюджується ID

Правильно, це виправлено. Але тепер FxCop поскаржиться на те, що Shoeстворює Shoelace, так Shoeмає бути IDisposableтеж.

І Driverтворити Shoeтак Driverтреба IDisposable. І Busтворити Driverтак Busтреба IDisposableі так далі.

Раптом моя невелика зміна на Shoelaceвикликає у мене багато роботи, і мій начальник цікавиться, чому мені потрібно оформити замовлення, Busщоб зробити зміни Shoelace.

Питання

Як ви запобігаєте цьому розповсюдженню IDisposable, але все ж забезпечуєте правильне розміщення ваших некерованих об'єктів?

Ви дійсно не можете "запобігти" розповсюдженню ідентифікаторів. Деякі класи повинні бути розміщені, як AutoResetEvent, і найефективніший спосіб - це зробити Dispose()методом, щоб уникнути накладних витрат фіналізаторів. Але цей метод слід називати якось так, як саме у вашому прикладі класи, які інкапсулюють або містять IDisposable, мають розпоряджатися цими, тому вони також мають бути одноразовими тощо. Єдиний спосіб уникнути цього - це:

• уникайте використання ідентифікаційних класів, де це можливо, блокуйте або чекайте подій в одних місцях, зберігайте дорогі ресурси в одному місці тощо
• створюйте їх лише тоді, коли вам знадобляться, і розпоряджайтесь ними відразу після ( usingвізерунок)

В деяких випадках IDisposable можна ігнорувати, оскільки він підтримує необов'язковий випадок. Наприклад, WaitHandle реалізує IDisposable для підтримки названого Mutex. Якщо ім’я не використовується, метод Dispose нічого не робить. MemoryStream - ще один приклад, він не використовує системних ресурсів, і його реалізація Dispose також нічого не робить. Ретельне розмірковування про те, чи використовується некерований ресурс, чи не може бути повчальним. Так можна вивчити доступні джерела для бібліотек .net або використовувати декомпілятор.

З точки зору правильності, ви не можете запобігти поширенню IDisposable через об'єктне відношення, якщо батьківський об'єкт створює і по суті є дочірнім об'єктом, який тепер повинен бути одноразовим. FxCop правильний у цій ситуації, і батько повинен бути ідентифікованим.

Що ви можете зробити, це уникати додавання ідентифікатора до класу листів у вашій ієрархії об’єктів. Це не завжди легке завдання, але це цікава вправа. З логічної точки зору, немає причин, що ShoeLace потрібно одноразово використовувати. Замість того, щоб сюди додати WaitHandle, чи можна також додати асоціацію між ShoeLace та WaitHandle у точці, яку він використовує. Найпростіший спосіб - через екземпляр словника.

Якщо ви можете перемістити WaitHandle в нещільну асоціацію через карту в точці, де фактично використовується WaitHandle, ви можете розірвати цей ланцюжок.

Щоб запобігти IDisposableпоширенню, слід спробувати інкапсулювати використання одноразового предмета всередині одного методу. Спробуйте спроектувати Shoelaceінакше:

class Shoelace { 
  bool tied = false; 

  public void Tie() {

    using (var waitHandle = new AutoResetEvent(false)) {

      // you can even pass the disposable to other methods
      OtherMethod(waitHandle);

      // or hold it in a field (but FxCop will complain that your class is not disposable),
      // as long as you take control of its lifecycle
      _waitHandle = waitHandle;
      OtherMethodThatUsesTheWaitHandleFromTheField();

    } 

  }
} 

Обсяг ручки очікування обмежений Tieметодом, і класу не потрібно мати поле для одноразового використання, і тому не потрібно буде самостійно користуватися.

Оскільки ручка очікування є деталлю впровадження всередині Shoelace, вона не повинна жодним чином змінювати свій публічний інтерфейс, як-от додавання нового інтерфейсу в декларацію. Що буде тоді, коли вам більше не потрібно одноразове поле, ви видалите IDisposableдекларацію? Якщо ви думаєте про Shoelace абстракцію , ви швидко розумієте, що вона не повинна забруднюватися інфраструктурними залежностями, наприклад IDisposable. IDisposableповинні бути зарезервовані для класів, абстракція яких інкапсулює ресурс, який вимагає детермінованого очищення; тобто для класів, де одноразовість є частиною абстракції .

Це в основному те, що відбувається, коли ви змішуєте склад або агрегацію з класами одноразового використання. Як вже згадувалося, першим виходом було б відновлювати ручку очікування поза шнурок.

Сказавши це, ви можете значно скоротити шаблон одноразового використання, коли у вас немає некерованих ресурсів. (Я досі шукаю офіційну довідку для цього.)

Але ви можете опустити деструктор і GC.SuppressFinalize (це); а може, трохи очистити віртуальну порожнечу Dispose (bool disposition).

Цікаво, якщо Driverвизначено вище:

class Driver
{
    Shoe[] shoes = { new Shoe(), new Shoe() };
}

Тоді, коли Shoeзроблено IDisposable, FxCop (v1.36) не скаржиться, що так само Driverмає бути IDisposable.

Однак якщо це визначено так:

class Driver
{
    Shoe leftShoe = new Shoe();
    Shoe rightShoe = new Shoe();
}

тоді вона скаржиться.

Я підозрюю, що це лише обмеження FxCop, а не рішення, тому що в першій версії Shoeекземпляри все ще створюються Driverі все ще потрібно якось утилізувати.

Я не думаю, що існує технічний спосіб запобігти поширенню IDisposable, якщо ви будете тримати дизайн так щільно. Тоді варто задуматися, чи правильно підійде дизайн.

У вашому прикладі, я думаю, має сенс мати взуття власником шнурка, і, можливо, водій повинен володіти своїм взуттям. Однак автобус не повинен володіти водієм. Як правило, водії автобусів не прямують до автобусів до автобуса :) У випадку з водіями та взуттям, водії рідко роблять власне взуття, тобто вони насправді не "володіють ними".

Альтернативним дизайном може бути:

class Bus
{
   IDriver busDriver = null;
   public void SetDriver(IDriver d) { busDriver = d; }
}

class Driver : IDriver
{
   IShoePair shoes = null;
   public void PutShoesOn(IShoePair p) { shoes = p; }
}

class ShoePairWithDisposableLaces : IShoePair, IDisposable
{
   Shoelace lace = new Shoelace();
}

class Shoelace : IDisposable
{
   ...
}

Новий дизайн, на жаль, є складнішим, оскільки він вимагає додаткових класів для пристосування та утилізації конкретних примірників взуття та водіїв, але це ускладнення властиве вирішуваній проблемі. Хороша річ у тому, що автобуси більше не можна одноразово використовувати лише з метою утилізації шнурків.

Як щодо використання Інверсії управління?

class Bus
{
    private Driver busDriver;

    public Bus(Driver busDriver)
    {
        this.busDriver = busDriver;
    }
}

class Driver
{
    private Shoe[] shoes;

    public Driver(Shoe[] shoes)
    {
        this.shoes = shoes;
    }
}

class Shoe
{
    private Shoelace lace;

    public Shoe(Shoelace lace)
    {
        this.lace = lace;
    }
}

class Shoelace
{
    bool tied;
    private AutoResetEvent waitHandle;

    public Shoelace(bool tied, AutoResetEvent waitHandle)
    {
        this.tied = tied;
        this.waitHandle = waitHandle;
    }
}

class Program
{
    static void Main(string[] args)
    {
        using (var leftShoeWaitHandle = new AutoResetEvent(false))
        using (var rightShoeWaitHandle = new AutoResetEvent(false))
        {
            var bus = new Bus(new Driver(new[] {new Shoe(new Shoelace(false, leftShoeWaitHandle)),new Shoe(new Shoelace(false, rightShoeWaitHandle))}));
        }
    }
}