Каковы наилучшие методы проектирования по контрактному программированию

каковы наилучшие методы проектирования по контрактному программированию.

в колледже я изучил дизайн по контрактной парадигме (в среде OO) Мы узнали три способа решения проблемы:--1-->

1) полное Программирование : покрывает все возможные исключительные случаи в своем эффект (ср. Ин. Math)

2) номинальное программирования : только обещает правом эффектов, когда предпосылки. (действие иное неопределено)

3) оборонительные Программирование: используйте исключения, чтобы сигнализировать о незаконных вызовах методов

теперь мы сосредоточились в разных сценариях OO на правильном использовании в каждой ситуации,но мы не узнали, когда использовать... (В основном тактика, когда подкрепляется упражнением..)

теперь я думаю, что это очень, очень странно, что я не спросил моего учителя (но опять же, во время лекций, никто не сделал)

лично я никогда не использую nominal сейчас и, как правило, заменяю предварительные условия на исключения (поэтому я скорее использую: throws IllegalDivisionByZero, чем утверждение " предварительное условие: делитель должен отличаться от нуля) и только программа total, что имеет смысл (поэтому я бы не вернул обычное значение при делении на ноль), но этот метод основан только на личных выводах и нравится.

поэтому я прошу вас :

есть ли лучшие практики??

8
design-by-contract

5 ответов

Я не знал об этом подразделении, и это действительно не отражает мой опыт.

Общая Программирования практически невозможно. Вы не можете гарантировать, что охватите все исключительные случаи. Поэтому в основном вы должны ограничить свою область и отклонить ситуации, которые выходят за рамки (это роль предпосылки)

Номинальная Программирования не требуется. Неопределенный эффект должен быть запрещенный.

Защитное Программирование является обязательным. Вы всегда должны сигнализировать о незаконных вызовах методов.

Я выступаю за реализацию полных элементов проектирования по контракту, что, на мой взгляд, является практичной и доступной версией Общая Программирования

предпосылки (типа Защитное Программирование) сигнализировать о незаконном вызове метода. Попробуйте ограничить область действия как столько, сколько вы можете, чтобы вы могли упростить код. Избегайте сложной реализации, если это возможно, немного сужая область применения.

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

инварианты чтобы проверить, что согласованность объекта сохраняется.

5

все это сводится к тому, какие обязанности вы хотите возложить на клиента и исполнителем контракта.

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

другой момент-люди и фреймворки теперь имеют тенденцию реализовывать механизмы перевода исключений, которые используются в основном для перевода проверенных исключений (оборонительный стиль) в исключения времени выполнения, которые просто всплывают, если что-то не так. таким образом, клиент и исполнитель контракта должны меньше беспокоиться о том, имея дело с каждым другой.

опять же, это мое личное мнение, подкрепленное только тем ограниченным опытом, который у меня есть, я хотел бы услышать больше об этой теме.

1

...но мы не знаем, когда использовать который...

Я думаю, что лучшая практика-быть "как можно более оборонительным". Проверьте время выполнения, если можете. Как упоминал @MahdeTo, иногда это невозможно по причинам производительности; в таких случаях отступают на неопределенное или неудовлетворительное поведение.

тем не менее, будьте явными в вашей документации относительно того, что имеет проверки во время выполнения, а что нет.

1

Как и большая часть вычислений "это зависит", вероятно, лучший ответ.

проектирование по контракту / Программирование по контракту может значительно помочь развитию, явно документируя условия для функции. Просто документация может помочь, даже не превращая ее в (скомпилированный) код.

там, где это возможно, я рекомендую оборонительную проверку каждого условия. Но только для разработки и отладки. Таким образом, большинство неверных предположений пойманы, когда условия разбиты. Хорошая система сборки позволит вам включать и выключать различные типы условий на уровне модуля или файла, а также глобально.

действия, предпринятые в версиях выпуска программного обеспечения, зависят от системы и того, как запускается условие ( обычное различие между внешним и внутренним интерфейсами ). Версия выпуска может быть "total programming" - все условия дают определенный результат (который может включать ошибки или NaN)

Мне " номинальный программирование" - это тупик в реальном мире. Вы предполагаете, что если вы передали правильные значения (что, конечно, вы сделали), то значение, которое вы получаете, хорошо. Если ваше предположение было неверным - вы ломаетесь.

0

Я думаю, что тестовое программирование-это ответ. Перед фактической реализацией модуля сначала создается модульный тест (назовем его контрактом). Затем постепенно реализуйте функциональность и убедитесь, что контракт по-прежнему действителен. Обычно я начинаю с простых окурков и макетов, затем постепенно заполняю остальные, заменяя их настоящими. Продолжайте улучшать и делать тест сильнее. В конце концов, вы получите надежную реализацию указанного модуля плюс у вас есть фантастический тестовый стенд-закодированное выполнение контракта. Позже, если кто-то изменяет модуль, сначала вы видите, может ли он по-прежнему соответствовать испытательному стенду. Если это не так, контракт разорван-отклоните изменения. Или, контракт устарел, - исправьте модульные тесты. И так далее.. Скучный цикл разработки программного обеспечения :)

0