Comments 2
если вы используете не класс валидатора, а класс сообщения, у которого методом являтеся простая логика, соответствующая этому сообщению — " return age < 0" — возвращающая true/false, то ваш код станет коротким циклом по множеству объектов класса сообщений, сообщения можно будет ассоциировать только с полями, где они должны быть показаны, а не с целым юзером, сам код станет re-usable, сообщения и логику можно легко заменять/конфигурировать и тоже использовать в следующем проекте или даже в общей библиотеке валидаций и не только для сообщений об ошибках
причем в вашем варианте, скорее всего каждое следущее сообщение будет переписывать предыдущее, если условие выполняется, а класс сообщений может иметь дополнительный флаг, чтобы не проводить последующую валидацию, пока не ушла первая ошибка в этом же поле
идеально, конечно, использовать еще более абстрактный класс типа object/widget, но для небольших форм может быть достаточно класса «Message»
причем в вашем варианте, скорее всего каждое следущее сообщение будет переписывать предыдущее, если условие выполняется, а класс сообщений может иметь дополнительный флаг, чтобы не проводить последующую валидацию, пока не ушла первая ошибка в этом же поле
идеально, конечно, использовать еще более абстрактный класс типа object/widget, но для небольших форм может быть достаточно класса «Message»
Может вместо
public String getDescription() {}
использовать какой-нибудь > getErrorMessage. Исходя из своего опыта думаю что было бы хорошо еще расширить
boolean isValid(T value);
Проверяя по набору каких-нибудь Predicate и текст ошибки был привязан к Predicate, а не один текст для всех видов ошибок. Таким образом создавая Validator из набора Predicate(ов) можно и текст ошибки сделать локализированным и сам валидор будет более гибким.
Sign up to leave a comment.
Simple Field Validation