ну или билдер да)

Плюс можно пропускать что хочешь

я бы записал это в минусы

Го ещё третье наброшу

new Person( new Name('Alfred', 'Hitchcock'), new Lifetime('13-08-1899', '29-04-1980'), Appearance::withHeight(178), )

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

Нах в симфе сделали в ивенте stopPropagation. Причём без интерфейса

Плюс можно пропускать что хочешь

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

Нах в симфе сделали в ивенте stopPropagation. Причём без интерфейса

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

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

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

или addLetter()

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

давай мы не будем утрировать а начнем думать, а?

new Person( new Name('Alfred', 'Hitchcock'), new Lifetime('13-08-1899', '29-04-1980'), Appearance::withHeight(178), )

По мне, такой вариант вполне логичен

Создавать сущности для леттера не обязательно, поскольку уже есть php тип как string

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

вот тут даже мне смешно

По мне, такой вариант вполне логичен

я бы еще is moderated вынес из этой сущности, isAlive тебе lifetime скажет, тип - можно заменить на тип (композицией), страну проживания - там частенько не только страна, но список стран где жил и все такое...)

но идея четкая, вдруг я не хочу всю энтити менять а только букву изменить

Два переменных string, которые в купе означают имя человека - Name

Тестировать легче

но идея четкая, вдруг я не хочу всю энтити менять а только букву изменить

ну у тебя для этого определенно будет метод который будет это делать)))

setLetterAt(Letter $letter, Index $index) @throws IllegalArgumentException

а внутри еще пару assert

И когда с проектом имеете дело несколько лет, не забудете, какие поля имеют общую логику

То есть, семантику

но идея четкая, вдруг я не хочу всю энтити менять а только букву изменить

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

а внутри еще пару assert

мб тебе и не все имя нужно доставать а только first name тогда надо сделать getLetter и в цикле извлекать буквы до пробела где то там снаружи и так всю жизнь )))

да кароче

вот кейс рили

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

только давайте без группировки VO

там 10 полей от силы

давай мы не будем утрировать а начнем думать, а?

То есть ты реально будешь создавать отдельно классы Name, Lifetime и прочее? Ради чего? Если у тебя итак 50 классов, ты еще будешь их на составляющие разбивать?

То есть ты реально будешь создавать отдельно классы Name, Lifetime и прочее? Ради чего? Если у тебя итак 50 классов, ты еще будешь их на составляющие разбивать?

что бы не делать сервисы)

что бы не делать сервисы)

Какие еще сервисы?

а ну да, я забыл что вся логика в контроллерах

То есть ты реально будешь создавать отдельно классы Name, Lifetime и прочее? Ради чего? Если у тебя итак 50 классов, ты еще будешь их на составляющие разбивать?

для начала - добавить один маленький класс в котором вся логика по работе с этими конкретными данными - это просто, быстро и не отнимает много времени.

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

а потом такой сходил за кофе а там кто то уже вторую сотню классов дописывает )

и все маленькие и нужные

а потом такой сходил за кофе а там кто то уже вторую сотню классов дописывает )

сколько классов у тебя в проекте?

для начала - добавить один маленький класс в котором вся логика по работе с этими конкретными данными - это просто, быстро и не отнимает много времени.

Я сейчас только о целесообразности геттеров и сеттеров говорю

пока что в районе 50 что ли

это примерно по 10 на роут

но еще не вечер

Я сейчас только о целесообразности геттеров и сеттеров говорю

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

вот например

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

>setBirthdate('13-08-1899') ->setDieddate('29-04-1980') ->setIsAlive(false)

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

isAlive тут лишнее т.к. его и так можно вычислить

isAlive тут лишнее т.к. его и так можно вычислить

ну вот надо уточнить у автора кода как подразумевалось. Вполне возможно что isAilve захотят задавать руками

значит diedDate не нужен

т.к. будет ставиться в тот момент когда меняется isAlive

зачем усложнять?)

isAlive тут лишнее т.к. его и так можно вычислить

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

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

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

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

черновик?)

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

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

черновик?)

Я это для чата написал

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

важный момент - вот у тебя есть "данные" которые составляют статью. И вот у тебя есть хранилище. Что между этим происходит?

Для этого чата придумал первое что пришло вг олову

важный момент - вот у тебя есть "данные" которые составляют статью. И вот у тебя есть хранилище. Что между этим происходит?

Между чем "этим"?

Между этим я пью чай

Между чем "этим"?

логика есть между принял данные и сохранил? не валидация данных - а именно логика какая-то, ограничения и т.д

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

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

такое бывает не?

ERROR: S client not available

иногда

реальность такова что чем сложнее проект тем меньше вероятность что ты сделаешь "ок" с первого раза.

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

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

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

да, не сомневаюсь, где то у крутых пацанов bleeding edge technology разработки ) но я сомневаюсь что такие ребята будут поддерживать

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

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

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

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

го в истоки. Ивент по определению не должен это знать и контролировать. Давайте разделять event & mediator

го в истоки. Ивент по определению не должен это знать и контролировать. Давайте разделять event & mediator

он не знает и не контролирует, это делает диспатчер

но я с тобой согласен что это "странно" потому для своих ивентов я юзаю свой диспатчер который делает честный pub/sub и который нельзя "остановить"

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

но щито поделать)

т.к. будет ставиться в тот момент когда меняется isAlive

Вот еще один случай, когда нужен сеттер. Вытащил сущность из бд, вызвал $user->setDieddate(), внутри которого сразу устанавливается или снимается флаг isAlive. Или может статься, что проект разросся до огромных размеров, а ты везде использовал прямой доступ к аттрибутам класса, без геттера, а потом выяснилось, что при вызове $user->getGroup() сначала надо проверить, указана ли группа юзера напрямую, если нет, то взять группу из класса этого юзера, если и там нет, то взять дефолтную группу школы, к котрой принадлежит юзер. Тогда пришлось бы искать все случаи прямого доступа и заменять их на вызов геттера. Это настоящий use case из моего проекта. public function getGroup() { if ($this->group) { return $this->group; } if ($this->getClass()) { if ($this->getClass()->getGroup()) { return $this->getClass()->getGroup(); } } //just take the first one $groups = $this->getSchool()->getGroups(); if (count($groups)) { return $groups->first(); } return null; } Я не понимаю, что Сергей хочет мне доказать, когда целесообразность использования геттеров и сеттеров с самого начала очевидна.

Вот еще один случай, когда нужен сеттер. Вытащил сущность из бд, вызвал $user->setDieddate(), внутри которого сразу устанавливается или снимается флаг isAlive. Или может статься, что проект разросся до огромных размеров, а ты везде использовал прямой доступ к аттрибутам класса, без геттера, а потом выяснилось, что при вызове $user->getGroup() сначала надо проверить, указана ли группа юзера напрямую, если нет, то взять группу из класса этого юзера, если и там нет, то взять дефолтную группу школы, к котрой принадлежит юзер. Тогда пришлось бы искать все случаи прямого доступа и заменять их на вызов геттера. Это настоящий use case из моего проекта. public function getGroup() { if ($this->group) { return $this->group; } if ($this->getClass()) { if ($this->getClass()->getGroup()) { return $this->getClass()->getGroup(); } } //just take the first one $groups = $this->getSchool()->getGroups(); if (count($groups)) { return $groups->first(); } return null; } Я не понимаю, что Сергей хочет мне доказать, когда целесообразность использования геттеров и сеттеров с самого начала очевидна.

брат я с тобой

я бодался но меня забодали )

но щито поделать)

да вот и меня сильно удивляет. 4тая мажорная версия, многолет, многолюдей, но всё ещё остаются такие вещи

ну плиз, хотя бы не базовый класс без интерфейса

жирнющий ивент диспетчер (жирный интерфейс)

да, можно сделать свой интерфейс диспетчера, под которым спрятались адаптер

Вот еще один случай, когда нужен сеттер. Вытащил сущность из бд, вызвал $user->setDieddate(), внутри которого сразу устанавливается или снимается флаг isAlive. Или может статься, что проект разросся до огромных размеров, а ты везде использовал прямой доступ к аттрибутам класса, без геттера, а потом выяснилось, что при вызове $user->getGroup() сначала надо проверить, указана ли группа юзера напрямую, если нет, то взять группу из класса этого юзера, если и там нет, то взять дефолтную группу школы, к котрой принадлежит юзер. Тогда пришлось бы искать все случаи прямого доступа и заменять их на вызов геттера. Это настоящий use case из моего проекта. public function getGroup() { if ($this->group) { return $this->group; } if ($this->getClass()) { if ($this->getClass()->getGroup()) { return $this->getClass()->getGroup(); } } //just take the first one $groups = $this->getSchool()->getGroups(); if (count($groups)) { return $groups->first(); } return null; } Я не понимаю, что Сергей хочет мне доказать, когда целесообразность использования геттеров и сеттеров с самого начала очевидна.

> вызвал $user->setDieddate(), внутри которого сразу устанавливается или снимается флаг isAlive. а если я переименую этот метод в died() то он останется сеттером? > а ты везде использовал прямой доступ к аттрибутам класса, без геттера Ты не понимаешь в чем проблема - проблема что тебе понадобился доступ к группам изначально. А так, например для UI, геттеры норм

> Я не понимаю, что Сергей хочет мне доказать я ни в коем случае не хочу тебе доказать что "никогда не юзай геттеры/сеттеры". Это глупо, я сам ими пользуются часто. Я хочу что бы люди начали различать геттеры/сеттеры от просто методов и начали осознавать разницу, то как геттеры/сеттеры ломают инкапсуляцию, то как они повышают связанность и т.д. Повторюсь для ясности - если ты берешь сущность и в рамках операции вызваешь один единственный сеттер, и все, операция завершилась - то в этом нет ничего плохого. Вопрос остается в семантике но и так сойдет. С точки зрения связанности и гибкости никакой разницы с сеттером ты это делаешь или без.

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

все остальное - плевать в целом

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

блин дак, доступ к голым проперти - это нарушение инкапсуляции, а вызов сеттера то почему вдруг стал нарушением инкапсуляции? )

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

только потому что у элемента 10 переключалок вместо 3? )

блин дак, доступ к голым проперти - это нарушение инкапсуляции, а вызов сеттера то почему вдруг стал нарушением инкапсуляции? )

инкапсуляция это ...?

блин дак, доступ к голым проперти - это нарушение инкапсуляции, а вызов сеттера то почему вдруг стал нарушением инкапсуляции? )

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

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

я понял под инкапсуляцией вы понимаете "мало методов"