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

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

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

так почти везде)

Пытаюсь разобраться с валидацией Стоит ли писать предусловия в сеттерах entity с выкидыванием эксепшенов, если до этого при попадании из контроллера в сервис данные валидируются по тем же самым правилам? Или наоборот, стоит писать только 1 раз предусловия и не дублировать их в валидации на входе в сервис? С одной стороны вроде не рекомендуют использовать эксепшены для flow-control, а с другой программист-то может сетнуть что-то уже и после проверки в сервисе. А дублирование проверок выглядит подозрительно.

Пытаюсь разобраться с валидацией Стоит ли писать предусловия в сеттерах entity с выкидыванием эксепшенов, если до этого при попадании из контроллера в сервис данные валидируются по тем же самым правилам? Или наоборот, стоит писать только 1 раз предусловия и не дублировать их в валидации на входе в сервис? С одной стороны вроде не рекомендуют использовать эксепшены для flow-control, а с другой программист-то может сетнуть что-то уже и после проверки в сервисе. А дублирование проверок выглядит подозрительно.

есть очень большая разница между валидацией входящих данных и проверкой прекондишенов/инвариантов логики

Пытаюсь разобраться с валидацией Стоит ли писать предусловия в сеттерах entity с выкидыванием эксепшенов, если до этого при попадании из контроллера в сервис данные валидируются по тем же самым правилам? Или наоборот, стоит писать только 1 раз предусловия и не дублировать их в валидации на входе в сервис? С одной стороны вроде не рекомендуют использовать эксепшены для flow-control, а с другой программист-то может сетнуть что-то уже и после проверки в сервисе. А дублирование проверок выглядит подозрительно.

Одно дело - валидация реквестов, другое - логика домена. Ну и стоит подумать над необходимостью сеттеров.

есть очень большая разница между валидацией входящих данных и проверкой прекондишенов/инвариантов логики

то есть если например есть условие длины username < 10, то его (условия) дублирование во входящих данных и в прекондишене должно повторяться?

то есть если например есть условие длины username < 10, то его (условия) дублирование во входящих данных и в прекондишене должно повторяться?

а почему для бизнеса важно что бы длина юзернейма меньше 10-ти символов?

или это ты придумал?

над обновления проверить) с месяц назад обновлялся - ещё приходилось в инспектор игнор вколачивать)

пол года назад находил

а почему для бизнеса важно что бы длина юзернейма меньше 10-ти символов?

Например в БД больше 10 не помещается

норм бд)

или это ты придумал?

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

Например в БД больше 10 не помещается

почему? это требование бизнеса?

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

ну я об этом и говорю - половина правил валидации - не относятся к бизнес логике

Например в БД больше 10 не помещается

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

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

ну тупые базы обрежут строку

не зафэйлятся

ну тупые базы обрежут строку

negsv ,fpfv vj;yj cnhbrn vjl drk.xbnm)

но я все еще не понимаю откуда рождаются такие ограничения

тупым базам можно стрикт мод включить)

тупым базам можно стрикт мод включить)

ну да)

а почему для бизнеса важно что бы длина юзернейма меньше 10-ти символов?

PO бесят выпендрежники с длинными никнеймами и он несет эту боль за собой в проект. а вообще частенько бизнес любит включать сразу два проблемных синдрома 1) мы подглядели это где-нибудь и тоже теперь захотели вот так а на попытку переубедить и объяснить что это никому не нужно, а "где-то там" это внедрено либо по такому же принципу, либо по техническим ограничениям очень старым и неактуальным. либо просто идиоты. и тут включается 2) я тут босс и мне виднее, не спорь

хотя, кто с этим запаривается - другой вопрос

PO бесят выпендрежники с длинными никнеймами и он несет эту боль за собой в проект. а вообще частенько бизнес любит включать сразу два проблемных синдрома 1) мы подглядели это где-нибудь и тоже теперь захотели вот так а на попытку переубедить и объяснить что это никому не нужно, а "где-то там" это внедрено либо по такому же принципу, либо по техническим ограничениям очень старым и неактуальным. либо просто идиоты. и тут включается 2) я тут босс и мне виднее, не спорь

в обеих ситуациях загоняться по выразительности кода смысла нет ибо всеравно всем похуй

почему для бизнеса важна длина юзернейма? спроси это спам-ботов в телеграме посление месяцы ;)

почему для бизнеса важна длина юзернейма? спроси это спам-ботов в телеграме посление месяцы ;)

хороший кейс

почему для бизнеса важна длина юзернейма? спроси это спам-ботов в телеграме посление месяцы ;)

достаточно выпилить вхождения ссылок\email'ов\etc, длина то тут причём.

class Username(string $username) { if (strlen($username) > 10) { throw new InvalidArgumentException() } }

м... почему я не могу сделать никнейм vasya.ru?

м... почему я не могу сделать никнейм vasya.ru?

а почему я не могу сделать никнейм "бешанные коты из космоса с лапатой"?

v@sya.ru

м... почему я не могу сделать никнейм vasya.ru?

потому что сможешь им спамить если владельцам на это пофиг - можешь если не пофиг - не можешь

а почему я не могу сделать никнейм "бешанные коты из космоса с лапатой"?

м... напоминает мой вайфай пароль ;)

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

именно. Похожая тема с именем и фамилией

и когда ты араб

или прочие эдж кейсы

или фамилии нет

и когда ты араб

ждём национальность с использованием ссылок в ФИО.

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

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

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

в расслыках имя тоже вписывается в дизайн в какой-то мере если я в 99% буду обрезать имя, то в чем профит давать его такой вводить?

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

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

если ошибок 3 - фэйлиться на первой или важно все 3 показать

p.s. сеттеры рак

а что до дублирования правил - есть правило трех

и оно спасает от такиз загонов

в расслыках имя тоже вписывается в дизайн в какой-то мере если я в 99% буду обрезать имя, то в чем профит давать его такой вводить?

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

p.s. сеттеры рак

откуда здесь в обсуждении сеттеры всплыли? Оо

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

именно

а что до дублирования правил - есть правило трех

что за правило?

откуда здесь в обсуждении сеттеры всплыли? Оо

в начале дискуссии, там у него логика прекондишенов

что за правило?

google "правило трех рефакторинг"

в начале дискуссии, там у него логика прекондишенов

а, лол. странно что ты так поздно триггернулся )

https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

google "правило трех рефакторинг"

а, я понял про что ты. Точнее про правило трёх понял :D

прикол в том что не все штуки которые похожи являются дублированием

даже если ну вот совсем похожи

да, есть такое

и пока их только 2 похожих - лучше оставить пока не будет очевидно что это одно и то же

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

p.s. сеттеры рак

а какая альтернатива? Писать прекондишены в конструкторе?

а какая альтернатива? Писать прекондишены в конструкторе?

VO

можешь почитать про primitive obsession

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

сеттеры обычно плохи тем что на последнее им срать

ERROR: S client not available

а какая альтернатива? Писать прекондишены в конструкторе?

Альтернатива - понять зачем тебе эти сеттеры. Если жизненный цикл сущности чуть больше чем просто появиться и быть записанным в базу и необходимо менять состояние в зависимости от логики, то логику изменения состояния необходимо инкапсулировать в самой сущности.

но у тебя под "сеттерами" походу подразумеваются просто методы которрые меняют стэйт

я сейчас уточняю потому что у людей какое-то тупое разделение видов методов на геттеры и сеттеры бывает, а не command/query

хотя последнее имеется ввиду.

Альтернатива - понять зачем тебе эти сеттеры. Если жизненный цикл сущности чуть больше чем просто появиться и быть записанным в базу и необходимо менять состояние в зависимости от логики, то логику изменения состояния необходимо инкапсулировать в самой сущности.

звучит разумно

но стоит ли пихать туда то что непосредственно на инварианты объекта не влияет - это уже другой вопрос

как никак ограничения схемы твоей базы никакого отношения к доменной модели не имеет

иначе это будет протекание инфраструктуры в код

@jimke тогда если сущность просто записывается в базу - можно написать в конструкторе. Но если есть какая-то бизнес-логика, то в соответствующем методе (и он будет менять состояние, но будет не просто тупо сеттером)

хотя не, фигня какая-то

сеттеры для DTOошек и то если совсем лень думать и группировать)

хотя не, фигня какая-то

да, зачем, стэйт отдельно процедуры отдельно

так, я вот тут вас слушаю и у меня возникает более фундаментальный вопрос что вы считаете сеттером? Как я понял это сеттер: public function setX($x) { $this->x = $x; } А это уже не сеттер: public function setX($x) { if ($x > 5) { ... } ... } Правильно?

так, я вот тут вас слушаю и у меня возникает более фундаментальный вопрос что вы считаете сеттером? Как я понял это сеттер: public function setX($x) { $this->x = $x; } А это уже не сеттер: public function setX($x) { if ($x > 5) { ... } ... } Правильно?

сеттер - доступ к полю на запись. Все

не поведение а именно доступ к стэйту

значит до меня хоть что-то дошло :D

setStatus - сеттер, publish - команда, поведение

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

кто б мне так на работе моск вправлял

setUsername(string $username) : void{ $this->username = $username; } и rename(string $newUsername): void { $this->username = $newUsername; } разница маленькая, но существенная

от того, что в сеттере появится условие, он сеттером быть не перестанет)

ну тип того, важен смысл, семантик которую код несет

ну это уже с точки зрения кларити

семантика set name - "запихни стэйт"

семантика rename - переименуй.

если надо поменять весь стэйт - проще новый объект ебнуть

withName(string $username): self {}

опять-таки, не сеттер)

ну ты не можешь говорить о сеттерах если у тебя нет стэйта)

если надо поменять весь стэйт - проще новый объект ебнуть

а если объект большой? Копировать накладно

а если объект большой? Копировать накладно

но ты же ВЕСЬ стэйт всеравно меняешь, зачем копировать?

большой - это сколько?)