Коли використовувати [Pure] на конструкторі?

Я дізнаюся про кодові контракти в .NET, і я намагаюся зрозуміти ідею чистих конструкторів. Документація кодових контрактів зазначає:

Усі способи, які викликаються в рамках договору, повинні бути чистими; тобто вони не повинні оновлювати будь-який попередній стан. Чистим методом дозволяється змінювати об'єкти, створені після вступу в чистий метод.

А в PureAttributeдокументації зазначено:

Вказує на те, що тип чи метод чистий, тобто він не вносить видимих ​​змін у стан.

Я розумію ці твердження, коли мова йде про методи, а як щодо конструкторів? Припустимо, у вас був такий клас:

public class Foo
{
    public int Value { get; set; }

    public Foo(int value) {
        this.Value = value;
    }
}

Цей конструктор, очевидно, впливає на стан нового Fooоб'єкта, але він не має інших побічних ефектів (наприклад, він не маніпулює жодними параметрами та не викликає будь-які нечисті методи). Це кандидат [Pure]чи ні? Яке значення розміщення [Pure]атрибута на конструкторі, і коли я повинен це зробити у власному коді?

Ви прикрашаєте метод за допомогою [Pure]:

• Якщо метод не має побічних ефектів. Наприклад, якщо метод отримує доступ до бази даних та модифікує її або її результат залежить від бази даних, це не є чисто.

• І якщо ви розраховуєте використовувати його в кодових контрактах. Наприклад, якщо метод чистий , але ви не маєте наміру використовувати його в кодових контрактах, додавання [Pure]не матиме користі і не зробить ваш код швидшим.

Що стосується конструкторів, то, схоже, вони вважаються чистими в .NET і не потребують явного атрибуту. Я переглянув декілька конструкторів у джерелі .NET Framework, таких як атрибут у DateTimeних немає [Pure].

Я припускаю, що це робиться з кількох причин:

• Це може бути занадто недоцільним, щоб писати конструктор без параметрів з [Pure]атрибутом просто, щоб мати можливість використовувати клас / структуру в контракті.

• Деякі, наприклад String, не мають явних конструкторів.

• Конструктори отримують спеціальну обробку навіть поза кодовими контрактами; наприклад, не передбачається, що викидатимете винятки всередині них .

• [Pure]це лише умова, яка спрощує ваше життя, але немає фактичної статичної перевірки, щоб забезпечити чистоту методу, прикрашеного цим атрибутом. void DestroyDatabase()може вважатися чистою, а кодові договори не помітять нічого поганого.

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

  ^{З кодових контрактів №5: чистота методу}

• Сама .NET Framework містить конструктори, які не є чистими. Наприклад, List<T>(IEnumerable<T> collection)насправді нечисто, якщо прокручування колекції має побічні ефекти.

• Контракти кричатимуться просто. Я легко можу уявити собі такий контракт Contract.Requires(!string.IsNullOrEmpty(name)), тому є вагомі підстави оголосити статику string.IsNullOrEmptyчистою.

  З іншого боку, якщо вам потрібен a StringBuilderдля того, щоб побудувати рядок, який ви будете перевіряти, то на предмет чогось, зателефонувавши до примірника методу вашого бізнес-класу, ви, мабуть, зловживаєте контрактами. Ось чому також StringBuilder.ToStringне позначається як чистий, навіть якщо це може бути (чи не так?)

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