Шаблоны проектирования OO для проверки

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

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

Какую комбинацию шаблонов проектирования OO лучше всего решить? A factory может быть хорошим способом получить конкретный валидатор, но являются ли их лучшие подходы?

ОТВЕТЫ

Ответ 1

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

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

Откажитесь от пути и дайте валидаторам делать то, что они должны делать: 


for validator in all_validators:
    validator.validate(model)

Ответ 2

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

Каждый фильтр проверяет один "путь" (как вы их называете).
Сначала для синтаксиса, второй для поиска Db и т.д. (Со второго пуля).

Ответ 3

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

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

Ответ 4

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

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

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

new UserValidator().validate(user)

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

new UserPanelValidator().validate(userPanel)

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