Предусловия в конструкторах наследников

Существует одна типичная проблема с проверкой аргументов в конструкторах классов-наследников, которые должны передавать куски своих аргументов базовому классу. Простой пример этой проблемы выглядит так:abstract class Base
{
private readonly int _length,
protected Base(int length)
{
if (length <,= 0) throw new ArgumentOutOfRangeException('length'),
_length = length,
}
}
internal class Derived : Base
{
public Derived(string s)
:
base(s.Length)
{
// Проверка бесполезна!
if (string.IsNullOrEmpty(s
)) throw new ArgumentNullException('s'),
}
}

Проблема в том, что конструктор базового класса вызывается до тела метода конструктора Derived (*). В результате, если конструктор наследника принимает составной объект и выкусывает часть, которая нужна конструктору базовому классу, то нормально проверить валидность составного объекта не получиться.

(*) Строго говоря, это не так, и мы посмотрим, как Code Contracts обходят эту проблему.

В результате, приходится вытаскивать валидацию аргументов и выкусывание нужной информации во вспомогательный метод или выкручиваться каким-то другим образом.internal class Derived : Base
{
public Derived(string s)
:
base(ValidateAndExtractLength(s))
{ }
private static int ValidateAndExtractLength(string s)
{
if (string.IsNullOrEmpty(s)) throw new ArgumentNullException('s'),
return s.Length,
}
}

Данный подход работает, но теперь предусловия конструктора (которые являются ключевыми для клиентов класса) размазаны по вспомогательным статическим методам. Альтернатива воспользоваться контрактами (a.k.a. Code Contracts).abstract class Base
{
// дополнительные поля помогут понять, как действует
// компилятор языка C# и Code Contract Rewriter
private readonly int _baseFoo = 42
,
private readonly int _length,
protected Base(int length)
{
Contract.Requires(length >,= 0),
_length = length,
}
}
internal class Derived : Base
{
private readonly string _s,
private readonly int _derivedFoo = 36,
public Derived(string s)
:
base(s.Length)
{
Contract.Requires(!string.IsNullOrEmpty(s)),
_s = s,
}
}

Казалось бы, а в чем разница? Но она есть, и еще какая! Как и в случае с асинхронными методами и блоками итераторов, в случае предусловий в конструкторе, компилятор Code Contracts выполняет более сложное преобразование IL-кода, а не просто заменяет Contract.Requires на генерацию исключения.

ПРИМЕЧАНИЕ
Подробнее о предусловиях асинхронных методов см. Когда предусловия не являются предусловиями.

Приведенный выше код в откомпилированном виде будет выглядеть так:internal abstract class Base_Decompiled
{
private readonly int _baseFoo,
private readonly int _length,
protected Base_Decompiled(int length)
{
// Предусловия базового класса
__ContractsRuntime.Requires(length >,= 0, null, 'length >,= 0'
),
// Инициализатор полей базового класса
this._baseFoo = 42
,
// Вызов конструктора базового класса (System.Object-а)
base..ctor
(),
// Тело конструктора базового класса
this._length = length
,
}
}
internal class Derived_Decompiled : Base_Decompiled
{
private readonly string _s,
private readonly int _derivedFoo,
public Derived_Decompiled(string s)
{
// Предусловия класса-наследника
__ContractsRuntime.Requires
(
!string.IsNullOrEmpty(s), null, '!string.IsNullOrEmpty(s)'),
// Инициализатор полей класса-наследника
this._derivedFoo = 36
,
// Вызов конструктора класса-наследника
base..ctor(s.Length
),
// Тело конструктора класса-наследника
this._s = s,
}
}

Это значит, проверка предусловия класса наследника будет выполнена до вызова конструктор базового класса!

При наличии контрактов процесс конструирования экземпляра наследника будет таким:

• Проверка предусловий наследника: Contract.Requires(!string.IsNullOrEmpty(s)),
• Инициализатор полей наследника: _derivedFoo = 36,
• Вызов конструктора базового класса
• Проверка предусловия базового класса:
  Contract.Requires(length >,= 0),
  
• Инициализатор полей базового класса: _baseFoo = 42,
• Тело конструктора базового класса: _length = length,
• Тело конструктора класса-наследника: _s = s,

Существует два важных момента

Во-первых, магия с контрактами работает даже для так называемых Legacy Contract Requires: это значит, что для получения преимуществ контрактов достаточно добавить Contract.EndContractBlock после проверки аргументов.public Derived(string s)
:
base(s.Length)
{
if (string.IsNullOrEmpty(s))
throw new ArgumentNullException('s'),
Contract.EndContractBlock(),
}

А во-вторых, теперь должно быть понятным ограничение контрактов, которое не позволяют использовать поля объекта в предусловиях. Поэтому следующий код не компилируется:internal class Derived : Base
{
// Поле должно быть открытым, чтобы удовлетворять требованию
// доступности предусловий!
public readonly int N = 42
,
private readonly string _s,
public Derived(string s)
:
base(s.Length)
{
Contract.Requires(!string.IsNullOrEmpty(s)),
// error CC1011: This/Me cannot be used in Requires of a constructor
Contract.Requires(N == 42
),
_s = s,
}
}

З.Ы. Хотя контракты кажутся полудохлыми, они достаточно интенсивно используются в некоторых проектах внутри Майкрософт. Так, в новой билд-системе они используются на полную. Долгое время даже гоняли статический анализатор, хотя недавно от него все-таки отказались.