Документ описывает концепцию проектирования по контракту (Design by Contract, DBC), включая ее определение, практические аспекты и применение в программировании на C#. Он обсуждает утверждения, такие как предусловия и постусловия, а также инструменты для внедрения DBC, такие как библиотеки кода. Основное внимание уделяется важности формализации отношений между программными компонентами и их клиентами для повышения корректности и надежности кода.

1. Проектирование по
контракту
Сергей Тепляков, Visual C# MVP
.NET Architect at Luxoft
SergeyTeplyakov.blogspot.com

2. Agenda
• Базовые понятия контрактного
программирования
• Практические аспекты
• Библиотека Code Contracts
• Ограничения контрактов

3. Определение
Проектирование по контракту
(Design by Contract, DbC) – это
формализация отношений между
программным компонентом и его
клиентами

4. А нужно ли это?

5. Что скажете?
public interface IRepository
{
Customer GetCustomer(string id);
void SaveCustomer(Customer c);
}

6. Стандартное решение
• «Комментарии не лгут»
• На крайний случай «Use the Source
Luke!»

7. Давайте добавим немного
формальности!

8. О корректности ПО
• Код сам по себе, не является
корректным или некорректным!
• Важна спецификация
• «Задокументированный баг – это
фича!»

9. Утверждения в контрактах
• Предусловия
• Постусловия
• Инвариант класса
• Утверждения
• Инвариант цикла (Eiffel specific)

10. Внедрение спецификации в
код
class Repository : IRepository
{
public Customer GetCustomer(string id)
{
Contract.Requires(id != null);
Contract.Ensures(
Contract.Result<Customer>() != null);
}
}

11. Нарушения утверждений
• Нарушение предусловия – «баг» в
клиенте коде
• Нарушение постусловия, инварианта
или утверждения – «баг» в сервисе

12. Инструменты DbC
• Утверждения
• Статический анализатор
• Документация (DRY)

13. Контракты – это общее
понятие, которое покрывает
многие известные ОО
принципы

14. Принцип замещения Лисков
...если для каждого объекта o1 типа S
существует объект o2 типа T такой, что для
всех программ P, определенных в терминах T,
поведение P не изменяется при замене o2 на o1,
то S является подтипом (subtype) для T.

15. Принцип замещения Лисков

16. Метод Add
• ICollection.Add
• IList.Add
• Может ли метод добавлять 2
элемента?
• Или не добавлять ни одного?

17. Правила наследования
• Наследник может
• ослабевать предусловие
• усиливать постусловие
• Инварианты суммируются

18. Сильные и слабые условия
• X > 0 (слабее)
• X > 5 (сильнее, строже)

19. Предусловие и наследование

20. Отношение между типами

21. Ковариантность по типу
возвращаемого значения

22. Контравариантность
Action<in T>
static void Foo(object obj) { }
// Контравариантность аргументов:
// предусловие делегата Action<object> слабее
// предусловия Action<string>,
// поскольку typeof(object) > typeof(string)
Action<string> action1 = Foo;
// Или
Action<string> action2 = new Action<object>(Foo);
action1("Hello Foo!");

23. Ковариантность Func<out T>
static string Boo() { return "Boo"; }
// Ковариантность возвращаемого значения:
// постусловие делегата Func<string> сильнее
// постусловия Func<object>,
// поскольку typeof(string) < typeof(object)
Func<object> func1 = Boo;
// Или
Func<object> func2 = new Func<string>(Boo);

24. Ковариантность
исключений
class Base {
public:
virtual void Foo() throw(std::exception) {}
};
class Derived : public Base {
public:
/*override*/ void Foo() throw(std::logic_error) {}
};

25. Принцип самурая

26. Мониторинг утверждений
во время выполнения
• Уровни утверждений
• None
• Requires
• Ensures
• Full
• Assert on Contract Failures

27. Утверждения и внешние
данные

28. Контракты vs Защитное
программирование
Проверка Проверка при
предусловий каждом
(2 открытых обращении к
метода) полю (27 мест!)

29. Code Contracts
• Частичная поддержка в .NET 4.0
• Устанавливается отдельно:
• Статический анализатор
• Rewriter
• Генератор документации

30. Вернемся к методу Add
// From mscorlib.Contracts.dll
[ContractClassFor(typeof (ICollection<>))]
internal abstract class ICollectionContract<T> : ICollection<T>
{
public void Add(T item)
{
// Исходный контракт
Contract.Ensures(Count >= Contract.OldValue<int>(Count),
"this.Count >= Contract.OldValue(this.Count)");
// Мы могли бы добавить!
Contract.Ensures(Contains(item),
"Contains(item) should be true!");
}
}

31. Адаптация существующего
кода
• Уже есть класс Guard?
• Добавляем атрибут и получаем
предусловие!

32. Code Contracts
• Contract.Requires
• Contract.Ensures
• Contract.Invariant
• Contract.Assert/Assume

33. Альтернативная проверка
предусловий
public class SimpleClass
{
public int Foo(string s)
{
if (s == null)
throw new ArgumentNullException("s");
Contract.EndContractBlock();
return s.Length;
}
}

34. Альтернативная проверка
предусловий
public static class Guard
{
[ContractArgumentValidatorAttribute]
public static void IsNotNull<T>(T t) where T : class
{
if (t == null)
throw new ArgumentNullException("t");
Contract.EndContractBlock();
}
}

35. Ограничения DbC
• Аккуратнее со статическим
анализатором!
• Не переусердствуйте в
формализации
• Частичная поддержка Code
Contracts в .NET Framework

36. Важнейшие принципы DbC
• Разделение ответственности
• Упрощение обязанностей
• Обобщение существующих понятий
• Формализация отношений

37. Дополнительные материалы
• Бертран Мейер, “Объектно-ориентированное конструирование
программных систем”
• С. Тепляков, “Проектирование по контракту”, RSDN Magazine #1-
2010
• Programming Stuff. “Альтернативная проверка предусловий в Code
Contracts”
• Programming Stuff. “Принцип замещения Лисков и контракты”
• Programming Stuff. “Принцип самурая”
• Programming Stuff. “Как не надо писать код”
• Александр Бындю. “Дополнение к LSP”

38. Спасибо за внимание
• Сергей Тепляков, Visual C# MVP
• .NET Architect at Luxoft
• Sergey.Teplyakov@gmail.com
• http://sergeyteplyakov.blogspot.com/