Liskov Substitution Principle & Contracts

[@ApeCoder]

LSP это логическая конструкция. Если вы декларируете, что поддерживаете интерфейс X, а при этом поддерживаете только его ограниченное подмножество, то получается неправда.

[@mynameiszb]

Проблема не в том, что я декларирую. Проблема в том, что я использую библиотеки и интерфейсы сторонних разработчиков. Которые не считают нужным гарантировать свою «контрактную» составляющую.

И здесь приходится следовать рекомендациям создателей Contracts — «описывайте контрактные условия в старом стиле».

Фактически, из-за строгой соответствии LSP — я получаю список предупреждений на стыке между моими интерфейсами и чужими.

[@RoundGiraffe]

У меня вся статья меньше одного экрана.
Как-то больше похоже на небольшую личную заметку.
Ничего против, просто после такого заголовка ожидал что-то более широкое прочитать.

[@mynameiszb]

Я стараюсь не уподобляться бангалорским братьям, которые аккуратно копируют километры MSDN.

PS. Следующая статья про Conract & Interfaces чуть больше.

[@Igorbek]

Насколько я помню, есть какой-то способ создать контракты для библиотек.
Т.е. создать «внешнее» описание контракта библиотеки. Так поступет сам CodeContracts, предоставляя контракты для классов .Net.

[@ApeCoder]

Вот тут похоже

[@mynameiszb]

Создать контрактную библиотеку-враппер для того, чтобы добавить нужный слой проверок — это возможно. Просто нужно представить объем дополнительной работы в этом случае.

На мой взгляд, наиболее простое (не красивое, но простое) решение в данном случае — это использовать «старую нотификацию» для проверки: if () / throw new Exception…

В целом — библиотека контрактов не является обязательным средством разработки, но существенно облегчает жизнь. Поэтому и использовать этот инструмент стоит без излишнего фанатизма, принимая во внимание его ограничения…