Design by Contract basics
•Descargar como PPTX, PDF•
1 recomendación•675 vistas
Slides from dotnetconf conference about design by contract.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (19)
Similar a Design by Contract basics
Similar a Design by Contract basics (20)
Design by Contract basics
- 1. 4-я конференция .NET разработчиков 28 апреля 2012 Проектирование по контракту Сергей Тепляков, Visual C# MVP .NET Architect at Luxoft SergeyTeplyakov.blogspot.com
- 2. Контракты http://www.flickr.com/photos/lofink/4501610335/
- 3. О чем поговорим? • Базовые понятия контрактного программирования • Практические аспекты • Ограничения контрактов
- 4. Определение Проектирование по контракту (Design by Contract, DbC) – это формализация отношений между программным компонентом и его клиентами
- 5. А нужно ли это?
- 6. Что скажите? public interface IRepository { Customer GetCustomer(string id); void SaveCustomer(Customer c); }
- 7. Стандартное решение • «Комментарии не лгут» • На крайний случай «Use the Source Luke!»
- 8. Давайте добавим немного формальности!
- 9. О корректности ПО • Код сам по себе, не является корректным или некорректным! • Важна спецификация • «Задокументированный баг – это фича!»
- 10. Утверждения в контрактах • Предусловия • Постусловия • Инвариант класса • Утверждения • Инвариант цикла (Eiffel specific)
- 11. Внедрение спецификации в код class Repository : IRepository { public Customer GetCustomer(string id) { Contract.Requires(id != null); Contract.Ensures( Contract.Result<Customer>() != null); } }
- 12. Нарушения утверждений • Нарушение предусловия – «баг» в клиенте коде • Нарушение постусловия, инварианта или утверждения – «баг» в сервисе
- 13. Инструменты DbC • Утверждения • Статический анализатор • Документация (DRY)
- 14. Контракты – это общее понятие, которое покрывает многие известные ОО принципы
- 15. Принцип замещения Лисков ...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в терминах T, поведение P не изменяется при замене o2 на o1, то S является подтипом (subtype) для T.
- 17. Метод Add • ICollection.Add • IList.Add • Может ли метод добавлять 2 элемента? • Или не добавлять ни одного?
- 18. Правила наследования • Наследник может • ослабевать предусловие • усиливать постусловие • Инварианты суммируются
- 20. Ковариантность по типу возвращаемого значения
- 21. Другие примеры • .NET/C# • Ковариантность массивов в .NET • Ковариантность/контравариантность делегатов и интерфейсов • Java/C++ • Ковариантность исключений • Ковариантность возвращаемых типов
- 22. Контракты vs Защитное программирование Проверка Проверка при предусловий каждом (2 открытых обращении к метода) полю (27 мест!)
- 23. Code Contracts • Частичная поддержка в .NET 4.0 • Устанавливается отдельно: • Статический анализатор • Rewriter • Генератор документации
- 24. Утверждения и входные данные
- 25. Ограничения DbC • Аккуратнее со статическим анализатором! • Не переусердствуйте в формализации • Частичная поддержка Code Contracts в .NET Framework
- 26. Важнейшие принципы DbC • Разделение ответственности • Упрощение обязанностей • Обобщение существующих понятий • Формализация отношений
- 27. Дополнительные материалы • Бертран Мейер, “Объектно-ориентированное конструирование программных систем” • С. Тепляков, “Проектирование по контракту”, RSDN Magazine #1-2010 • Programming Stuff. “Альтернативная проверка предусловий в Code Contracts” • Programming Stuff. “Принцип замещения Лисков и контракты” • Programming Stuff. “Как не надо писать код” • Александр Бындю. “Дополнение к LSP”
- 28. Спасибо за внимание Сергей Тепляков, Visual C# MVP .NET Architect at Luxoft Sergey.Teplyakov@gmail.com http://sergeyteplyakov.blogspot.com/
Notas del editor
- Такие слова, как «формализация» или «спецификация» чужды и страшны большинству разработчиков. Сразу же возникает вопрос: а стоит ли затевать весь этот сыр-бор ради этого? Чем не подходят старые, проверенные временем практики, без всяких там контрактов?
- А что если описать отношения между классом (или интерфейсом) и его клиентами более формальным образом.Например, можно сказать, что я сделаю свою работу, но только в том случае, если свою работу сделает вызывающий код.Таким образом, мы четко разделим отношения класса и его клиенты; каждый из них будет точно знать, на что рассчитывать от другой стороны и не будет перепроверять это по десять раз.Кстати, обратите внимание, что я не говорю о тотальной формализации отношений, зачастую достаточно разделить эти обязанности в вашей голове, чтобы такое разделение нашло отражение в вашем коде и дизайне.Но прежде чем переходить к способам разделения ответственностей, давайте рассмотрим еще одну важную характеристику.Я думаю, что многие разработчики спорят друг с другом во время код или дизайн ревью (или с представителями отдела качества) о том, содержит ли баг некоторый фрагмент кода или нет.
- Сейчас существует огромное множество различных паттернов, принципов, идиом, которые должны помочь в создании хорошего дизайна. Я ничего не имею, например, против принципов SOLID, но у меня есть совет, как их лучше запомнить и, главное, как ими лучше пользоваться на практике.На самом деле, контрактное программирование (прошу, не путайте с конкретными библиотеками, типа Code Contracts) – это отличный инструмент в борьбе за хороший дизайн.Для начала, давайте рассмотрим один из SOLID принципов: принцип замещения Лисков. Именно на нем строится очень важный аспект любой ОО модели, поскольку он лежит в основе полиморфного поведения.Может стоит сказать о том, что в самой навороченной книге по ООП – в книге Бертрана Мейера описано очень мало разных принципов. Из известных есть только Open Closed.