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

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

class HasDisposableClassField
{
    private DisposableClass disposableClass;
}

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

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

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

Ответ 1

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

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

Ответ 2

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

Помещение чего-то в свойство не магически распоряжается им для вас.

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

Ответ 3

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

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

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

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

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