Объединять ли код валидации формы добавления и редактирования, если поля почти одинаковые?

Question

[Sekira]

Допустим, есть гостевая книга, в которую могут писать и гости, и зарегистрированные пользователи. Зарегистрированные еще могут редактировать свои сообщения.

Так как поля текст, email и т.п., одни и те же, кроме имя гостя, то напрашивается объединение валидации всех полей и одного поля уже с проверкой по условию, зарегистрирован или нет. Затем также идет insert или update, опять же проверки те же самые практически.

Так вот, если всё это объединять и делать постоянные условия если это гость или нет, это вставка или редактирование, то получается какая-то каша, зато все проверки, в одном месте, например максимальная длина текста, или регулярка email, а если разделить отдельно, то получается три почти одинаковых кода. И если потом вздумается что-то поменять в валидации, то менять придется в трех местах и можно что-нибудь упустить.

Как лучше это сделать? Спасибо!

Comments

[abcd0x00]

Если так стоит вопрос - объединить и получить что-то или разделить и получить это же, то лучше разделить, чем объединить.

Вот ты думаешь "я там буду одинаково email'ы проверять, поэтому объединю их, и так сэкономлю код, тесты и прочее". А потом раз, и у зарегистированных пользователей с email'ом надо что-то делать (или не делать), и происходит это в следующей версии программы (в далёком будущем). И что твой сокращённый код, что твои немногочисленные тесты, помогут они тебе в этом? Нет, придётся всё разделять сидеть (тратить время на разделение).

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

Answer 1

[romy4]

объединять. это общая практика.
если что-то можно использовать два раза — это надо сделать.

Comments

[Sekira]

Просто не дают покоя эти постоянные проверки/условия, например конструкция вида:

prepare("INSERT ... " . ($isUser ? "`user_id`=:user_id" : "`guest`=:guest") . ", ...

if($isUser)
	bindValue(':user_id', $data_user['user_id'], PDO::PARAM_INT);
else
	bindValue(':guest', $_POST['guest'], PDO::PARAM_STR);

// А в некоторых базах и такого INSERT нет, то вообще получается вот такой шедевр:
"INSERT INTO `table` (" . ($isUser ? "`user_id`" : "`guest`") . ", `email`,...) VALUES (" . ($isUser ? ":user_id" : ":guest") . ", :email,...)

[romy4]

Sekira: Программировение — это всегда проверки и условия

Answer 2

[tema_sun]

Вам нужна одна форма ModelForm и пара вьюшек унаследованных от CreateView и UpdateView

Comments

[tema_sun]

Прошу прощения, с чего-то решил, что речь о Django. Пора спать, пожалуй)

Answer 3

[M-ka]

Ну представляю что то типа:
закрытая область видимости содержащая список полей и правил, что с ними можно делать
поле1:
правило1: событие1:выполнить1, событие2: (выполнить2, выполнить3, выполнить4),
правило2: событие1:выполнить2, событие2: выполнить4
поле2:
правило1: событие2: выполнить7,
правило2: событие3:(выполнить5, выполнить3, выполнить4)

приватный метод установки событий полей с разделением по правилам, что с ними делать
приватный метод инита, вызывающий проставление события для полей
публичные методы на добавление информации через приватный
публичный метод на редактирование информации через приватный

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