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

Question

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

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

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

2) Номинальное программирование: только «обещает» правильные эффекты при выполнении предварительных условий. (иначе эффект не определен)

3) Защитное программирование: использовать исключения для сигнализации о недопустимых вызовах методов

Теперь, мы сосредоточились в различных OO-сценариях на правильном использовании в каждой ситуации, но мы не научились КОГДА использовать ЧТО ... (В основном это тактика, основанная на упражнении ..)

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

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

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

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

Answer 1

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

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

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

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

Я за реализацию полных элементов «Дизайн по контракту», которая, на мой взгляд, является практичной и доступной версией Всего программирования

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

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

Инварианты для проверки сохранения целостности объекта.

Answer 2

... но мы не узнали, КОГДА использовать КОГО ...

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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