ОО-шаблоны проектирования, используемые для проверки

Question

Я нахожусь в процессе написания некоторого кода проверки на основе этих предположений:

• Код проверки должен быть во внешнем классе
  • т.е. ни один класс данных не содержит свою собственную проверку
• Один и тот же объект может быть проверен разными способами.
  • например. проверять только синтаксис; проверить на соответствие БД; проверить на наличие дубликатов; и т.д.
• Результат проверки может быть разным в зависимости от того, что ему нужно
  • например. вывести одно сообщение об ошибке; вывести список всех ошибок валидации; аналогично, но в формате JSON и с кодами ошибок; и т.д.

Какая комбинация шаблонов проектирования ОО является лучшей для решения этой проблемы? Фабрика может быть хорошим способом получить определенный валидатор, но лучше ли их подойти?

Answer 1

Один размер подходит не всем! Сделай это просто!

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

Уйдите с пути и дайте валидаторам делать то, что они должны делать: <pre> for validator in all_validators: validator.validate(model)

Answer 2

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

Каждый фильтр проверяется по одному «пути» (как вы их называете).
Первый - для синтаксиса, второй - для поиска в БД и т. Д. (Из второго пункта).

Answer 3

Если вы выполняете какую-либо работу с GUI, вам следует взглянуть на JGoodies Validation: http://www.jgoodies.com/downloads/libraries.html (также некоторые статьи здесь: www.jgoodies.com/articles/).

Я бы создал валидатор для любого класса, который нуждается в валидации. Вы можете создать более одного валидатора, если вам нужны разные способы валидации, например, строгий или нет. Вы можете сгруппировать общие функции и методы в классы, такие как AbstractValidator и ValidationResult (которые могут иметь список ошибок, серьезности и т. Д.).

Остерегайтесь чрезмерного дизайна. Попробуйте начать с чего-то простого, например:

new UserValidator().validate(user)

или для проверки представления:

new UserPanelValidator().validate(userPanel)

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

Answer 4

У меня была такая же проблема, и я обнаружил, что шаблон посетителя действительно эффективен при отделении логики проверки от объекта данных. Вам необходимо оборудовать иерархию классов данных с помощью методов accept (visitor), но если вы создаете все, это достаточно просто. Даже если вы используете стороннюю иерархию без поддержки посетителей, вы можете создавать оболочки, предоставляющие дерево обхода accept, и это довольно близко к методу внутри класса.

Чтобы выполнить другую валидацию, вы реализуете другой класс валидатора и передаете его методу accept корневого объекта. Я также смог создать других посетителей утилиты вокруг модели, что позволило мне создать посетитель генератора, который заполнил все поля выборочными / случайными данными. Я немного рассердился на посетителя, потому что был так взволнован. Вы, вероятно, можете сказать, что я все еще взволнован, особенно если есть возможность рассказать об этом кому-то еще.