Каковы лучшие практики для Дизайна Программирования по контракту
Вы довольно близко. Запрос будет выглядеть следующим образом:
SELECT u.id, u.firstname, u.lastname,
um.meta_value as user_att1
FROM users u JOIN
users_meta um
ON u.id = um.user_id AND
um.meta_key = 'user_att1' AND
um.meta_value = '1'
ORDER BY ID DESC
LIMIT 0, 20 ;
Агрегирование не требуется, и если вы хотите фильтровать по значению, сравнение должно быть в предложениях ON, WHERE или HAVING.
5 ответов
Я не знал об этом разделении, и оно не совсем соответствует моему опыту.
Полное программирование практически невозможно. Вы не можете гарантировать, что покроете все исключительные случаи. Так что, по сути, вы должны ограничить свой объем и отклонить ситуации, которые выходят за рамки (это роль Предварительных условий )
Номинальное программирование нежелательно. Неопределенный эффект должен быть запрещен.
Защитное программирование является обязательным. Вы всегда должны сигнализировать о незаконных вызовах методов.
Я за реализацию полных элементов Design-by-Contract, а именно: на мой взгляд, это практичная и доступная версия Total Programming
Preconditions (своего рода Defensive Programming ), сигнализирующая о незаконном вызове метода. Постарайтесь максимально ограничить область действия, чтобы упростить код. По возможности избегайте сложной реализации, немного сузив область действия.
Постусловия , которые вызывают ошибку, если желаемый эффект не достигается. Даже если это ваша вина, вы должны уведомить вызывающего абонента о том, что вы не достигли своей цели.
Инварианты для проверки сохранения целостности объекта.
Постусловия , вызывающие ошибку, если желаемый эффект не достигается. Даже если это ваша вина, вы должны уведомить вызывающего абонента о том, что вы не достигли своей цели.
Инварианты для проверки сохранения целостности объекта.
Постусловия , вызывающие ошибку, если желаемый эффект не достигается. Даже если это ваша вина, вы должны уведомить вызывающего абонента о том, что вы не достигли своей цели.
Инварианты для проверки сохранения целостности объекта.
... но мы не узнали, КОГДА использовать то, ЧТО ...
Я думаю, что лучшая практика - быть "как можно более оборонительным". Делайте проверки во время выполнения, если можете. Как @MahdeTo упоминал, что иногда это невозможно по причинам производительности; в таких случаях используйте ненадлежащее или неудовлетворительное поведение.
Тем не менее, в вашей документации следует четко указать, что имеет проверки во время выполнения, а что нет.
Все сводится к тому, какие обязанности вы хотите назначить клиенту и исполнителю контракта.
В защитном программировании вы заставляете исполнителя проверять наличие ошибок. условия, которые могут быть дорогостоящими или даже невозможными в некоторых случаях. Представьте себе контракт, указанный в binarySearch, например, ваш входной массив должен быть отсортирован. Вы не можете обнаружить это во время работы алгоритма. Вы должны выполнить ручную проверку, которая фактически увеличит время выполнения на порядок. Подтверждением моего мнения является сигнатура метода из Javadocs .
Другой момент - люди и фреймворки, как правило, реализующие механизмы трансляции исключений, которые используются в основном для перевода проверенных исключений (защитный стиль) в исключения времени выполнения, которые просто всплывают, если что-то происходит не так. таким образом, клиент и исполнитель контракта будут меньше беспокоиться, имея дело друг с другом.
Опять же, это мое личное мнение, основанное только на том, какой у меня ограниченный опыт, я хотел бы услышать больше об этом предмете.
Опять же, это мое личное мнение, подкрепленное только тем ограниченным опытом, который я имею, и я бы хотел узнать больше об этом предмете.
Опять же, это мое личное мнение, подкрепленное только тем ограниченным опытом, который я имею, и я бы хотел узнать больше об этом предмете.
Я думаю, что тестовое программирование - это ответ. Перед фактической реализацией модуля вы сначала создаете модульный тест (назовите его контрактом). Затем постепенно реализуйте функциональность и убедитесь, что договор остается в силе на ходу. Обычно я начинаю с простых заглушек и макетов, затем постепенно заполняю остальные, заменяя удары реальными вещами. Продолжайте улучшать и делать тест сильнее. В конце концов вы получаете надежную реализацию указанного модуля, плюс у вас есть фантастическая тестовая среда - кодированная реализация контракта. Позже, если кто-то модифицирует модуль, сначала вы увидите, может ли он все еще соответствовать тестовой площадке. Если этого не произойдет, договор нарушен - отклоните изменения. Или контракт устарел, - исправьте юнит-тесты. И так далее. Скучный цикл разработки программного обеспечения:)
Как и большинство вычислений, «это зависит», вероятно, лучший ответ.
Проектирование по контракту / программирование по контракту может значительно помочь в разработке, явно задокументировав условия для функции. Просто документация может помочь, даже не превращая ее в (скомпилированный) код.
Где это возможно, я рекомендую защищаться - проверять каждое условие. НО только для разработки и отладки. Таким образом, большинство неверных допущений обнаруживаются при нарушении условий. Хорошая система сборки позволит вам включать и выключать различные типы условий на уровне модуля или файла, а также в глобальном масштабе.
Действия, выполняемые в выпусках программного обеспечения, зависят от системы и от того, как условие запускается. (обычное различие между внешним и внутренним интерфейсами). Версия выпуска может быть «тотальным программированием» - все условия дают определенный результат (который может включать ошибки или NaN)
Для меня «номинальное программирование» - это тупик в реальном мире. Вы предполагаете, что если вы передали правильные значения в (что, конечно, вы сделали), то полученное значение является хорошим. Если ваше предположение было неверным - вы сломались.