просто странный подход к вопросу. Зачем делать задачи, которые часами молотятся?

цена отказа в их обработке как-то великовата

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

где-то грустят эрлангисты)

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

нету кафки, есть кролик

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

сервер сдох

.

что ты думаешь о напалме? зло или нет?

я это сравнение в рамочку сохраню, пожалуй

твоё гениальное решение слишком гениальное) суть вопроса не о том была)

ну ты часто юзаешь у себя в коде их?

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

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

ну, геттер позволяет получить приватное свойство объекта извне, сеттер позволяет установить это свойство

сеттеров нет, я ленивая жопа, поэтому сразу вхерачиваю рефлексией) но это всякие ДТОшки и мир не страдает :)

ну, геттер позволяет получить приватное свойство объекта извне, сеттер позволяет установить это свойство

User::rename(Username $username) подходит под твоё определение сеттера

ну, геттер позволяет получить приватное свойство объекта извне, сеттер позволяет установить это свойство

setName($fistName, $lastName) { $this->firstName = $firstName; $this->lastName = $lastName; } это сеттер?

а с ним не всё так просто

setName($fistName, $lastName) { $this->firstName = $firstName; $this->lastName = $lastName; } это сеттер?

ну да

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

к контролю над состоянием они отношения не имеют. Это скорее призыв всем желающим нагадить в стейте

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

не контроль, а оголить твой объект на самом-то деле

ну да

ну нет, потому что тут нет уже явной связи с приватными свойствами)

согласен, про приватные я зря сказал

нет, не зря

в этом суть

сеттер (в моей трактовке) - это доступ к свойству (одному) на запись

setName($fistName, $lastName) { $this->firstName = $firstName; $this->lastName = $lastName; } это сеттер?

Нет!

если у тебя метод делает что-то с несколькими полями - он уже не сеттер а просто метод

в этом большая разница

Согласен

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

даже банальные rename вместо setName уже отличается

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

хорошая аналогия

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

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

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

Вот здесь и нюанс. Если это классический сеттер (как иде генерит) - ты по факту оставляешь и доступ к стейту, причём полный. и заодно полностью открываешь структуру объекта. Более, кхм, кастомные сеттеры типа того же setName, который фесор привёл, задают контракт для изменения объекта, засчёт чего сложнее получать невалидный стейт. ну и семантика, все дела. rename > setName.

сеттер это не более чем договоренность - что мол вот если у меня есть свойство name то для доступа на запись (если я таковой предоставляю) я сделаю тебе метод setName

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

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

сеттер это не более чем договоренность - что мол вот если у меня есть свойство name то для доступа на запись (если я таковой предоставляю) я сделаю тебе метод setName

хорошее описание

с таким определением намного проще потом переходить к теме "а зачем вообще нам давать доступ к стэйту объекта кому-то извне")

на запись в этом нет вообще никакого смысла, на чтение - есть нюансы с тем как используется значение - если оно потом в if запихивается (и не для проверки на null) то это уже попахивает

еще пару раз встречал людей которые разделение на геттеры и сеттеры использовали в виду того что не знали про CQS. Ну мол, у них геттер это любой метод который что-то возвращает, а сеттер любой метод который мутирует состояние)

с такими формулировками очень сложно обсуждать что как и почему

еще пару раз встречал людей которые разделение на геттеры и сеттеры использовали в виду того что не знали про CQS. Ну мол, у них геттер это любой метод который что-то возвращает, а сеттер любой метод который мутирует состояние)

а ацессоры и мутаторы это просто синонимы для геттеров-сеттеров?

а ацессоры и мутаторы это просто синонимы для геттеров-сеттеров?

в целом да

но есть нюансы)

У меня такой вопрос: пусть у меня что-то наподобие "агрегата" Новость, есть агрегат "Реклама", которая может быть сделана на основе новости (а может и нет). Для формы создания я должен вытягивать пул новостей. Как правильно тащить новости: тащить из репы Новостей, дублировать в репе Реклама, но со своей семантикой или разруливать ивентами?

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

У меня такой вопрос: пусть у меня что-то наподобие "агрегата" Новость, есть агрегат "Реклама", которая может быть сделана на основе новости (а может и нет). Для формы создания я должен вытягивать пул новостей. Как правильно тащить новости: тащить из репы Новостей, дублировать в репе Реклама, но со своей семантикой или разруливать ивентами?

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

Т.е. ивенты остаются

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

но опять же надо думать. иногда так не выходит

p.s. ивент листенеры подходят на роль штуки сверху

p.s. ивент листенеры подходят на роль штуки сверху

я про них и думал. Еще момент: может ли запущенный ивент возвращать результат? Например, подключаемые модули должны вносить свои пункты в меню. Соответственно что-то кидает ивент, подписчики заполняют данными...?

BaseController хреновая тема правда ж? куда мне засунуть общие функции типа getFormErrorMessages(FormInterface $form) - cоздать валидатор сервис?

Composition over Inheritance

я про них и думал. Еще момент: может ли запущенный ивент возвращать результат? Например, подключаемые модули должны вносить свои пункты в меню. Соответственно что-то кидает ивент, подписчики заполняют данными...?

это ивент. его задача чисто уведомить что что-то произошло (и это что-то реально произошло а не собирается произойти)

пропонуєш вирішити це трейтом?

BaseController хреновая тема правда ж? куда мне засунуть общие функции типа getFormErrorMessages(FormInterface $form) - cоздать валидатор сервис?

в случае с контроллерами все не так очевидно

но если можешь хапихнуть что-то в сервис - лучше так и сделать)

пропонуєш вирішити це трейтом?

лучше уж базовый контроллер...

суть в том что в контроллерах не должно быть логики особо)

а если там нет логики то похеру

нет логики -> нет if-ов

кода там может быть до жопы

чисто координация действий

ок спс

А кто что использует для конвертации DTO <=> Entity?

руки

Наткнулся на https://github.com/mark-gerarts/automapper-plus - никто не использовал?

руки

А где происходит конвертация? $entity->createDTO(); ?

А где происходит конвертация? $entity->createDTO(); ?

ты не поверишь

ровно как и где происходит обратное

ровно как и где происходит обратное

таки сущность генерит DTO и заполняется из DTO? почему не наоборот?

таки сущность генерит DTO и заполняется из DTO? почему не наоборот?

наоборот?) плодить пачку геттеров?) такое себе. Это потом плохо закончится)

зато сущность не знает о существовании дто, по идее это не её зона ответственности, кмк ну с Entity => DTO соглашусь, можно конечно упороться по идее выше и сделать что-то вроде getInfo():array у сущности и лепить DTO из этого массива, но тогда этот массив уже суть есть DTO и в чём смысл. а вот DTO => Entity в самой Entity как-то, яхз. почему-то не нравится, но не могу объяснить почему.

dto -> entity = Entity::fromSomeDto(SomeDto) ок

dto -> entity = Entity::fromSomeDto(SomeDto) ок

нуууууууууу..... навееееерное даааа.... мне больше билдеры нравятся)

зато сущность не знает о существовании дто, по идее это не её зона ответственности, кмк ну с Entity => DTO соглашусь, можно конечно упороться по идее выше и сделать что-то вроде getInfo():array у сущности и лепить DTO из этого массива, но тогда этот массив уже суть есть DTO и в чём смысл. а вот DTO => Entity в самой Entity как-то, яхз. почему-то не нравится, но не могу объяснить почему.

если мы говорим про слои, то сущность может знать о DTO если эта DTO лежит в том же слое что и сущность)

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

p.s. часто слои переоценены, часто dto на чтение вообще не нужны особо, ну мол классы

если мы говорим про слои, то сущность может знать о DTO если эта DTO лежит в том же слое что и сущность)

нет use - нет проблем?

нет use - нет проблем?

нет, весь вопрос только в направлениях зависимостей

кто когда и с кем меняется и к чему относится

нуууууууууу..... навееееерное даааа.... мне больше билдеры нравятся)

а билдер через reflection заполняет сущность?

нуууууууууу..... навееееерное даааа.... мне больше билдеры нравятся)

зависит от смысла той дтошки. Если это команда какая, почему бы и да

а билдер через reflection заполняет сущность?

мне нравилось билдер в конструктор передавать. Это было бы удобнее будь в php поддержва package level visibility

вот в java билдеры вообще красиво

зависит от смысла той дтошки. Если это команда какая, почему бы и да

да, согласен. но это важный момент как по мне)

да, согласен. но это важный момент как по мне)

Уххх, если бы оборачивать все мысли в код и выносить в GIST, то не придется периодически возвращаться к обсасыванию обсасонной темы + к наглядности +1005000 и -1005000 к хаосу

Уххх, если бы оборачивать все мысли в код и выносить в GIST, то не придется периодически возвращаться к обсасыванию обсасонной темы + к наглядности +1005000 и -1005000 к хаосу

попахивает сказкой)