какой из них сеттер а какой "не очень"

Ну так там все методы сеттеры

Ну так там все методы сеттеры

ммм.... сча еще один добавлю но он будет отличаться

какой из них сеттер а какой "не очень"

Как по мне, то 1 и 2 такое себе )

1 и 4

https://gist.github.com/fesor/c02162883181276e3f7eda8c657d352f

А остальный 3-5 норм

добавил 6-ой метод

Ну так там все методы сеттеры

6-ой метод куда отнесешь?

4,5,6 не сеттеры)0

4,5,6 не сеттеры)0

а что?

6-ой метод куда отнесешь?

в ломбард

6-ой метод куда отнесешь?

Сложно) наверное к геттеру, вообще надо подумать

3,4,5 норм сеттеры, 6 просто метод, т.к. он не меняет состояние

4ый как завещал делать yegor256

Да, 6й просто метод

итого имеем.... - нет единого мнения относительно того что такое геттер и сеттер - судя по сомнениям куда относить 6-ой метод нет четкого понимания что такое сайд эффекты

все первых 5 это сеттеры

последний это просто часть процесса

все первых 5 это сеттеры

а 6-ой?

последний это просто часть процесса

а первые 5 не часть процесса?

верифи тут зачем вообще, он не сеттер

суть сеттера - поменять данные объекта

1-5 меняют, 6 нет

Но по сути 6-й можно к гетеру отнести

1-5 меняют, 6 нет

все 6 порождают сайд эффекты

бля пятый сложно пиздец

Но по сути 6-й можно к гетеру отнести

нельзя, он ничего не возвращает и он кидает исключения (сайд эффекты)

бля пятый сложно пиздец

Domain Event )

ты еще один варик не засунул туда

нельзя, он ничего не возвращает и он кидает исключения (сайд эффекты)

Почему не возвращает, какраз возвращает но в виде исключения.

ты еще один варик не засунул туда

?

Почему не возвращает, какраз возвращает но в виде исключения.

это сайд эффект.

public function setEmail($email){ $result = clone this; $result->email = $email; return $result; }

Domain Event )

по сути $this->rememberThat(EmailChangedEvent::occurred($this->id, $email)); надо бы вынести в листнер какойто

это сеттер? )

public function setEmail($email){ $result = clone this; $result->email = $email; return $result; }

отличный пример к слову

по сути $this->rememberThat(EmailChangedEvent::occurred($this->id, $email)); надо бы вынести в листнер какойто

ммм.... зачем? что бы выстрелить потом себе в ногу из базуки?

это сайд эффект.

Как мо мне, гетер возвращает информацию, а сетер изменяет. В 6 варианте, это получение информации о валидности токена.

public function setEmail($email){ $result = clone this; $result->email = $email; return $result; }

Это не сеттер думаю, не меняет же состояние

Это не сеттер думаю, не меняет же состояние

по факту - да, это геттер так как сайд эффектов нет)

но вспомним такую чудную функцию как array_pop и подумаем куда ее отнести

а если штука меняет состояние ее надо именовать с set ?))

а если штука меняет состояние ее надо именовать с set ?))

вопрос нэйминга пока оставим в стороне

а если штука меняет состояние ее надо именовать с set ?))

Естественно, иначе пых не скомпилируется

В итоге сеттре - то то что меняет состояние?

В итоге сеттре - то то что меняет состояние?

в итоге термины геттер и сеттер можно просто перестать использовать)

и пора дописывать статью про то "что такое сайд эффекты"

да, предлагаю переименовать геттер в "получатор" а сеттер в "записатор"

https://habrastorage.org/getpro/habr/post_images/197/881/52c/19788152ce3e82130a114639483dd2d3.png

да, предлагаю переименовать геттер в "получатор" а сеттер в "записатор"

уже есть четко определенные термины - команды и запросы)

нельзя, он ничего не возвращает и он кидает исключения (сайд эффекты)

А я еще встречал такое обозначение как isser ) Так вот 6-е это оно )

да, предлагаю переименовать геттер в "получатор" а сеттер в "записатор"

еще принтор и отправлятор для полноты диалекта

уже есть четко определенные термины - команды и запросы)

Тогда 6-й вариант, что по твоему? )

и моделировать исходя из доступных терминов))

Тогда 6-й вариант, что по твоему? )

команда)

и моделировать исходя из доступных терминов))

MultiButtSupporter

бля я б не стал писать как номер 6

команда)

Тоесть если я верну bool это будет запрос, а когда исключение команда ? )

бля я б не стал писать как номер 6

верю) тут мало кто так пишет.

Тоесть если я верну bool это будет запрос, а когда исключение команда ? )

да, вполне себе логично)

мне ближе что то вроде if ($user->setEmail($email)){ $eventDispatcher->dispatch(new UserEmailChangedEvent($user)); }

мне ближе что то вроде if ($user->setEmail($email)){ $eventDispatcher->dispatch(new UserEmailChangedEvent($user)); }

я за тебя рад

да, вполне себе логично)

Не логично ) По скольку код делает одно и тоже ... возвращает валидность токена. И каким образом возвращается результат помоему нет никакой разницы.

а что делает rememberMeThat?

мне ближе что то вроде if ($user->setEmail($email)){ $eventDispatcher->dispatch(new UserEmailChangedEvent($user)); }

зачеим иф?

затем что setEmail не кидает исключение а ласково говорит return false

мне ближе что то вроде if ($user->setEmail($email)){ $eventDispatcher->dispatch(new UserEmailChangedEvent($user)); }

Фиогово, покскольку у тебя тупая зависимость от eventDispatcher ... а этого в Entity быть не может

ERROR: S client not available

а что делает rememberMeThat?

у сущности есть просто массив того что с ней происходило. Оно просто добавляет ивент в массивчик

Фиогово, покскольку у тебя тупая зависимость от eventDispatcher ... а этого в Entity быть не может

а у него это и не в энтити)

затем что setEmail не кидает исключение а ласково говорит return false

бля помоему не оч

если убрать if придется делать try catch

а у него это и не в энтити)

Да, проебал, сонный ) Тогда толку от той энтити )

Не логично ) По скольку код делает одно и тоже ... возвращает валидность токена. И каким образом возвращается результат помоему нет никакой разницы.

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

Да, проебал, сонный ) Тогда толку от той энтити )

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

если убрать if придется делать try catch

зачем? что бы поиграть в go?

если убрать if придется делать try catch

А, понел. А может название поменять на change

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

Ну я выходил конкретно из этого примера. Просто если состояние не меняется, то по сути это запрос.

А, понел. А может название поменять на change

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

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

Угу, читал. Согласен.

зачем? что бы поиграть в go?

не понял тут )

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

неплохое замечание

не понял тут )

вот и я не понял зачем делать try/catch

затем что option 3

тут есть такой момент

правило большого пальца для исключений - исключительная ситуация не является ожидаемой

кривой емайл от криворукого юзера - ожидаемо

затем что option 3

окей, а что если все хорошо, исключения небыло но при сохранении в базу что-то не так пошло? а ты уже ивент кинул на обработку и уже email послать успел

поэтому тут можно и нужно обходиться без исключений

кривой емайл от криворукого юзера - ожидаемо

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

неплохое замечание

тоесть setEmail у тебя просто метод сущности?

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

вот да, это уже пиздец

тоесть setEmail у тебя просто метод сущности?

а надо чтобы он ракеты к марсу запускал? )

сам же сказал пятый вариант сложный

а надо чтобы он ракеты к марсу запускал? )

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

https://gist.github.com/fesor/c02162883181276e3f7eda8c657d352f

А есть пример как оно внутри выглядит? EmailChangedEvent::occurred($this->id, $email)

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

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

типа $user->setAggressiveMode(true)

))))))))))))