Комментарии 7
LSP это логическая конструкция. Если вы декларируете, что поддерживаете интерфейс X, а при этом поддерживаете только его ограниченное подмножество, то получается неправда.
Проблема не в том, что я декларирую. Проблема в том, что я использую библиотеки и интерфейсы сторонних разработчиков. Которые не считают нужным гарантировать свою «контрактную» составляющую.
И здесь приходится следовать рекомендациям создателей Contracts — «описывайте контрактные условия в старом стиле».
Фактически, из-за строгой соответствии LSP — я получаю список предупреждений на стыке между моими интерфейсами и чужими.
И здесь приходится следовать рекомендациям создателей Contracts — «описывайте контрактные условия в старом стиле».
Фактически, из-за строгой соответствии LSP — я получаю список предупреждений на стыке между моими интерфейсами и чужими.
У меня вся статья меньше одного экрана.
Как-то больше похоже на небольшую личную заметку.
Ничего против, просто после такого заголовка ожидал что-то более широкое прочитать.
Как-то больше похоже на небольшую личную заметку.
Ничего против, просто после такого заголовка ожидал что-то более широкое прочитать.
Насколько я помню, есть какой-то способ создать контракты для библиотек.
Т.е. создать «внешнее» описание контракта библиотеки. Так поступет сам CodeContracts, предоставляя контракты для классов .Net.
Т.е. создать «внешнее» описание контракта библиотеки. Так поступет сам CodeContracts, предоставляя контракты для классов .Net.
Создать контрактную библиотеку-враппер для того, чтобы добавить нужный слой проверок — это возможно. Просто нужно представить объем дополнительной работы в этом случае.
На мой взгляд, наиболее простое (не красивое, но простое) решение в данном случае — это использовать «старую нотификацию» для проверки: if () / throw new Exception…
В целом — библиотека контрактов не является обязательным средством разработки, но существенно облегчает жизнь. Поэтому и использовать этот инструмент стоит без излишнего фанатизма, принимая во внимание его ограничения…
На мой взгляд, наиболее простое (не красивое, но простое) решение в данном случае — это использовать «старую нотификацию» для проверки: if () / throw new Exception…
В целом — библиотека контрактов не является обязательным средством разработки, но существенно облегчает жизнь. Поэтому и использовать этот инструмент стоит без излишнего фанатизма, принимая во внимание его ограничения…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Liskov Substitution Principle & Contracts