Должен ли я использовать спецификации для простой логики проверки?

Question

В последнее время я читал о спецификациях, и я очень люблю их использовать. Однако я боюсь переусердствовать.

Например, если у меня есть пользовательский объект с свойством номера телефона, мне нужно ввести тест спецификации номера телефона в сеттер или достаточно логика проверки в сеттер?

Спасибо, Фил

UPDATE: Для больше контекста: Я думаю, что я хотел бы валидация быть в домене, а не в презентации. Я буду выполнять проверку в представлении, но это будет скорее функция пользовательского интерфейса. Идея (я считаю) заключается в том, что домен не может находиться в недопустимом состоянии и не может полагаться на презентацию. На самом деле у меня есть номер телефона Entity, и у многих объектов есть номера телефонов, хотя я полагаю, что это может стоить объект, но это еще одна дискуссия :)

Мне просто интересно, не переусердствовал ли он использовать Спецификации в Property-установщиках. Одно из преимуществ, которое я мог видеть, заключается в том, что спецификации могут делиться между уровнями, то есть с уровнем представления, чтобы вы могли делиться кодом проверки.

Как вы можете видеть, я не уверен, что это правильный подход.

Большое спасибо, Phil

Answer 1

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

«Номер телефона пользователя, действительный», вероятно, является хорошим состоянием сообщения для вашей функции сеттера. Однако у вас есть 2 варианта предварительного условия: (1) сделать это предпосылкой вашей функции setter, что все, что передано ей, является допустимым или (2) сделать намного более легкое предварительное условие для вашей функции setter и выполнить проверку ошибок в вашей функции сеттера. Вариант (1) по существу передает ответственность за проверку клиенту. Вариант (2) наделяет ваш пользовательский объект ответственностью за обработку ошибок.

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

Вот несколько ссылок для инвариантов и дизайна по контракту: http://svengrand.blogspot.com/2008/11/preconditions-postconditions-invariants.html http://en.wikibooks.org/wiki/Computer_Programming/Design_by_Contract