Наследование интерфейсов и контракты

В моем энтерпрайзе мне постоянно приходится думать над следующим: я вижу метод, принимающий некоторый объект. Обычно, подсовывать null туда нельзя, но в редких случаях, и если очень хочется то можно. Т.е. чтобы понять, что мне нужно сделать, мне нужно читать код, а там можем быть полотно спагетти-кода на пару экранов.

Тоже самое касается и постусловий. Если класс, у которого есть коллекция в виде какого-то свойства. В большинство людей используют пустую коллекцию, и никогда не возвращают null, но это далеко не всегда. Постусловие в этом плане четко скажет, чего ожидать от этого свойства (или возвращающего значения метода).

Да, в большинстве случаев более или менее сложные предусловия и постусловия живут в библиотеках, но некоторые бизнес-правила тоже можно формализовать. В целом так: исключения типа ArgumentNullException, InvalidArgumentEception, ArgumentOutOfRangeExcpetion все заменяются на соответствующие предусловия (ведь все эти исключения, на самом деле выбрасываются при нарушении предусловий). С постусловиями и инвариантами сложнее, поскольку они внутренние по отношению к вызывающему коду.

В целом, рассмотрение взаимоотношений классов через призму контрактов позволяет мне понять, сферы ответственности обоих классов, и кто кому что должен. Опять таки, если поднимутся вопросы с некоторыми принципами, типа Liskov Substitution Principle, то контракты здесь очень ок.

Ну и очень ОК использование контрактов для интерфейсов, понять семантику которых только исходя из документации весьма сложно.

Нет, в контракте описывается, что сотрудник и должность должны быть ненулевыми, и что после выполнения метода сотрудник все еще остается ненулевым.

Насчёт тестов — да, контракты позволяют писать тесты в декларативной форме. Равно как и не из описания в комментариях, а из утверждений контракта класса понять что он делает, что он требует и что гарантирует. Более явно это преимущество будет после интеграции наработок по Spec# в одну из будущих версий C#.

Также контракты позволяют формировать автоматические тесты, работать по CDD(Contract-Driven Development) (по аналогии с TDD). Под .Net есть интересная разработка «Pex» (идёт вместе с «Moles»), которая учитывает контракты при построении автоматических white-тестов.

По поводу БД — можно использовать описание котрактов через готовые модели (библиотеки классов, исключительно используемую для проверки контрактов).

Под .Net контракты только появились и выгода в их использовании пока ещё не столь очевидна из-за того, что различные инструменты, которые могли бы их использовать в полной мере всё ещё развиваются. Те же наработки для Eiffel-я по непрерывным фоновым автоматическим тестам, предложенями компилятора по исправлению ичастков кода, параллельному программированию, когда котракты выступают в роли механизма синхронизации потоков и пр.

ИМХО при текущей поддержке контрактов в .Net среде их выгодя для Enterprise не столь очевидна, но их следует применять хотя бы для того чтобы писать более обдуманный код, делиться предположениями/ожиданиями реализации с коллегами, которые потом будут переиспользовать ваш класс, да и просто на будущее, т.к. у контрактов очень большие перспективы.

Предусловия: сотрудник и должность не нулевые
Постусловие: счёт сотрудника увеличился (хотя бы не уменьшился)
Инвариант: счёт неотрицательный

У меня последняя версия.

public int Count
{
get
{
// We should add some hints to static checker to eliminate a warning
// Contract.Ensures(Contract.Result() == _backingList.Count);
return _backingList.Count;
}
}


Закомментируйте строку с Contract.Ensures, тогда предупреждение появится, что статик чекер не может гарантировать удовлетворение одного из постусловий.