Реализация IDisposable - одноразовые поля или одноразовые свойства

Question

Я выполнял анализ кода VS2013 в одном из моих текущих проектов и натолкнулся на «CA1001: Типы, которые имеют одноразовые поля, должны быть одноразовыми». Простой пример, который генерирует предупреждение (предполагая DisposableClass орудия IDisposable) является:

class HasDisposableClassField 
{ 
    private DisposableClass disposableClass; 
} 

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

class HasDisposableClassProperty 
{ 
    private DisposableClass disposableClass { get; set; } 
    public HasDisposableClassProperty() 
    { 
     disposableClass = new DisposableClass(); 
    } 
} 

В первом случае ясно, что класс должен реализовывать IDisposable шаблон, и утилизировать ее disposableClass поле соответствующим образом. Мой вопрос: является ли отсутствие предупреждения для второго случая ограничением инструмента анализа кода? Должен ли класс по-прежнему реализовывать IDisposable и распоряжаться этим свойством, несмотря на отсутствие предупреждения?

Answer 1

Да, отсутствие предупреждения является ограничением инструмента анализа.

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

Answer 2

Да; вам все равно нужно избавиться от него.

Помещение чего-то в собственность не волшебным образом избавляет вас от этого.

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

Answer 3

Реализация одноразового использования должна зависеть от того, как создаются ресурсы, которые нуждаются в утилизации (будь то одноразовые или не управляемые).

Если ваш объект получает ресурс посредством инъекции (конструктор, метод или свойство), он, вероятно, не владеет им и поэтому должен, вероятно, не избавиться от него.

Как хранится ресурс (локальная переменная, поле или свойство (с полем резервного копирования) не имеет значения), однако вам может потребоваться проверить, что ваш ресурс не был удален извне, поскольку ваш объект не является его владелец.

Если ваш класс создает ресурс напрямую (с помощью create, allocate, open handle, factory method), он, вероятно, владеет этим, и поэтому должен, вероятно, распоряжаться им.

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