Насколько активно стоит использовать контрактное программирование в проектах и как правильно?
Столкнулся первый раз и не могу понять насколько полезная штука, с первого взгляда кажется очень заманчивым.
P.S. Желательно применительно к C#.
Ответы
Ответ 1
Уже дали в комментах ссылку на мой пост "Начать ли использовать контракты", но, ИМХО, есть смысл дать краткую выжимку.
Дизайн - это дело сложное. Обычно сложность заключается в том, что не понятно, чт
каждый класс/модуль должен делать, может делать и как их правильно использовать: каки
"правильные" входные значения, в каком порядке нужно дергать методы и т.п. Другими словами
очень сложно глядя на абстрактный код в вакууме сказать, каким образом правильно пользоваться этим классом или, если речь идет о самом процессе проектирования, как "правильно" разбить обязанности между классами, чтобы система не развалилась под собственной тяжестью. Сходу сложно сказать, является ли текущее поведение фичей, багом, или просто не подумали.
Контракты сами по себе - вещь относительно простая, - это способ задания ожидаемог
поведения (еще это назвают спецификацией) в виде утверждений (assertions). Например
метод может "потребовать" у вызывающего кода валидную строку на вход, после чего он "обязуется" вернуть ее размер. Если же входное условие не будет выполнено, то никаких гарантий по результату не будет.
Фундаментальная идея, которая лежит в основе контрактов, помогает отсечь из безграничног
списка возможных состояний лишь те, которые интересны в данном контексте (читай, для данной задачи). Почему это важно? Да просто потому, что сложность растет очень быстро и без каких-то ухищрений забодает даже самую светлую голову.
Вот пример, который я обычно привожу (он несколько абстрактен, к сожалению).
Допустим, у нас есть класс с тремя булевыми полями: b1, b2, b3. Каково число возможны
состояний объекта этого класса? Правильно, 2 ^ 3, т.е. 8. А что если там мы добавим еще 2 булевых поля? То общее число состояний увеличится до 32.
Причем здесь контракты? Допустим, что в нашем объекте с 5 булевыми полями не вс
комбинации возможны. И с помощью предусловий конструктора, мы можем ограничить число возможных состояний лишь определенным понятным всем подмножеством. Вот надуманный пример:
class StupidClass
{
public StupidClass(bool b1, bool b2, bool b3)
{
// Утверждаем, что если b1 == true, то остальные два значения должны быть false.
// Иначе, утверждаем, что b2 или b3 могут быть true.
}
}
Пример дурацкий и не самый удачный, но он показывает, как можно с помощью валидаци
аргументов конструктора "сузить" пространство решений с 8 возможных комбинаций до, например, 2-х или трех. Это называется умным понятием инварианта, что имеет полезные практические последствия в виде уменьшения числа возможных "а что если".
Все это может показаться не важным, когда задача у вас в голове и все вот эти допущени
для вас совершенно очевидны. Но, поверьте, они перестанут быть очевидными через пару месяцев даже для вас, и точно будут совершенно не очевидными для постороннего мозга.
Теперь, если я, вдруг, заинтересовал этой темой, то готов поделиться дополнительным
ссылками для изучения этого дела. Я, наверное, один из самых больших поклонников контрактного программирования в рунете, что вылилось в десятки статей/сообщений и в участие в проекте Code Contracts.
Вот вмнеяемый набор ссылок.
Базовые вещи, чтобы понять, что это такое и нужно ли это.
Начать ли использовать контракты? - уже было. Повторенье, ученье, мать его:)
Как не надо писать код - Тут как раз я сравниваю на практике, в чем выгоды от использования проектирования по контракту для борьбы со сложностью.
Более академические статьи
Проектирование по контракту. Корректность ПО
Проектирование по контракту. Утверждения
Утверждения и защитное программирование
Проектирование по контракту. Наследование
Мониторинг утверждений в период выполнения
Контракты, состояние и юнит-тесты
Специфичное для Code Contracts
Наследование интерфейсов и контракты
Предусловия в конструкторах наследников
Когда предусловия не являются предусловиями
Комментариев нет:
Отправить комментарий