@fes0r за сеттером может скрываться более сложная логика. Допустим есть у меня объект расписания (типа с понедельника по четверг с 10:00 до 20:00, пятница с 10 до 17:00, суббота, воскресение - выходной). И по этой "маске", нужно сгенерировать расписание на год. Естественно, это удобнее всего спрятать за сеттером расписания. Ну вот он вроде бы просто сеттер, а логика в нем есть. Почему именно сеттер? Ну потому, что гидратор через них работает. Зачем вообще гидратор? Потому, что я получаю с бэка модели, как-то их изменяю, и в том же виде отправляю назад.

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

> Естественно, это удобнее всего спрятать за сеттером расписания. а я просто возвращаю итератор)

$slots = $schedule->availableSlots() foreach ($slots as $slot) { // делаем дела }

без гет как то нипанятна

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

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

причем тут битовая маска?)

@fes0r за сеттером может скрываться более сложная логика. Допустим есть у меня объект расписания (типа с понедельника по четверг с 10:00 до 20:00, пятница с 10 до 17:00, суббота, воскресение - выходной). И по этой "маске", нужно сгенерировать расписание на год. Естественно, это удобнее всего спрятать за сеттером расписания. Ну вот он вроде бы просто сеттер, а логика в нем есть. Почему именно сеттер? Ну потому, что гидратор через них работает. Зачем вообще гидратор? Потому, что я получаю с бэка модели, как-то их изменяю, и в том же виде отправляю назад.

чет не пойму причем тут гидратор

это же сериализация/десериализация не?

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

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

ну я бы засунул штуку с битовой маской куда-то в сервис какой-то

но не в сущность

в сеттер

и у меня нет "бинарных масок"

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

@fes0r за сеттером может скрываться более сложная логика. Допустим есть у меня объект расписания (типа с понедельника по четверг с 10:00 до 20:00, пятница с 10 до 17:00, суббота, воскресение - выходной). И по этой "маске", нужно сгенерировать расписание на год. Естественно, это удобнее всего спрятать за сеттером расписания. Ну вот он вроде бы просто сеттер, а логика в нем есть. Почему именно сеттер? Ну потому, что гидратор через них работает. Зачем вообще гидратор? Потому, что я получаю с бэка модели, как-то их изменяю, и в том же виде отправляю назад.

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

и я могу попробовать ее решить)

$slots = $schedule->availableSlots() foreach ($slots as $slot) { // делаем дела }

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

и у меня нет никаких сеттеров и прочей чуши для этого. Поменялось рассписание - новый инстанс Schedule

p.s. пока ты подтверждаешь смешание понятия "сеттер" и "просто метод" + подтверждаешь цитатами про graphql влияние UI на то как ты производишь декомпозицию))

блин почему я тут вижу лишь бунт против конвенции

что со мной не так

блин почему я тут вижу лишь бунт против конвенции

конвенции "есть данные и есть процедуры"?

конвенция гет получает данные объекта, сет устанавливает

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

блин почему я тут вижу лишь бунт против конвенции

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

хм )

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

идея в декомпозиции и семантике)

не могу сказать что это что-то "меньшее"

можт лучше не сеттерыгеттеры обсуждать тогда а анемичные и рич модели ?)

а то все на нейминг сводится

можт лучше не сеттерыгеттеры обсуждать тогда а анемичные и рич модели ?)

да, можно так)

нэйминг это вторая сложная проблема программирования

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

а еще можно только с позиции связанности кода обсуждать какахи

не могу сказать что это что-то "меньшее"

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

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

ммм.... а чем ты это представлял?

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

про связанность надо гуглить идти

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

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

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

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

если нельзя то что делать...

это все про инкапсуляцию (проведение границ по сути, границы "капсул"), декомпозицию, абстракцию и т.д.

слушай у меня есть дурацкий вопрос. смотри какое дело. есть User; private $firstName; private $lastName; метод setFullName($fullName){ $e = explode(" ", $fullName, 2); $this->firstName = $e[0]; $this->lastName=$e[1]; } будет считаться сеттером?

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

какая-то глупость

какая-то глупость

дурацкий вопрос

я бы сделал так: class Name { private $first; private $last; private function __construct(string $firstName, string $lastName) { $this->first = $firstName; $this->last = $lastName; } public static function fromString(strign $fullName) { $parts = explode(" ", $fullName, 2); return new self($parts[0], $parts[1]); } }

и делай себе

$user->setName(Name::fromString('Alan Kay'));

и че потом опять его делать persist ?

и че потом опять его делать persist ?

почитай про embeddable, это не сущность

и че потом опять его делать persist ?

ну и паралельно почитай про каскадный персист

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

и все усложнить на пустом месте? )

сервис заведи и менеджер )))

ui никак не влияет. Это просто подход. Я не ввожу "какие-то-там-данные". Я получаю с бэка модели, модифицирую их на фронте, отправляю их назад в том же виде, в каком получил. Это очень ускоряет разработку. Вот и всё. Если что-то добавилось, какие-то события возникли или, что-то еще случилось, всё это обрабатывается в сеттерах. Вся логика сводится к $hydrator->hydrate(Model::class, $data); $em->flush();В гидраторе уже есть резолверы, которые могут вытащить модели из базы или создать новые модели, в зависимости от того, представлен ли идентификатор(ы). Валидация примитивов происходит на уровне graphql. Сложные проверки - в сеттерах. Может не очень хорошее для них название. Но они такие, да.

и все усложнить на пустом месте? )

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

для одного метода нужен один дополнительный объект

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

не бойся заводить маленькие классы

и для 10 разных энтити с 5 методами надо хм 50 промежуточных объектов

ui никак не влияет. Это просто подход. Я не ввожу "какие-то-там-данные". Я получаю с бэка модели, модифицирую их на фронте, отправляю их назад в том же виде, в каком получил. Это очень ускоряет разработку. Вот и всё. Если что-то добавилось, какие-то события возникли или, что-то еще случилось, всё это обрабатывается в сеттерах. Вся логика сводится к $hydrator->hydrate(Model::class, $data); $em->flush();В гидраторе уже есть резолверы, которые могут вытащить модели из базы или создать новые модели, в зависимости от того, представлен ли идентификатор(ы). Валидация примитивов происходит на уровне graphql. Сложные проверки - в сеттерах. Может не очень хорошее для них название. Но они такие, да.

то есть ты юзаешь "гидраторы" для "замены стэйта объектов"?

не бойся заводить маленькие классы

зачем

зачем классы, 10 разных процедур!)

и для 10 разных энтити с 5 методами надо хм 50 промежуточных объектов

или 20 сервисов менеджеров которые невозможно покрыть юнитами, да)

ERROR: S client not available

это уже ооп ради ооп приправленое сверху иммутабельным соусом

это уже ооп ради ооп приправленое сверху иммутабельным соусом

давай так

ты пробовал?

вот честно, ты просто отвергаешь, это не критический взгляд на вещи

ты пытаешься доказать свою точку зрения

не пытаясь даже ее проверить

это не "силвер булет"

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

я ленивый

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

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

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

что если я тебе скажу что работы по факту будет меньше?)

(но думать придется больше конечно, а думать больно да)))

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

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

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

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

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

я еще раз повторюсь - попробуй, сделай себе домашний проект и попробуй реализовать)

только не CRUD

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

прям такой увидел класс Name и пошел у фаулера читать что это такое)

не, прям зашел в папку а там 50 мелких классов по 2 параметра

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

и ты не представляешь насколько такой подход упрощает введение в проект

не, прям зашел в папку а там 50 мелких классов по 2 параметра

дтошки и VO

сложно понять, да

не, прям зашел в папку а там 50 мелких классов по 2 параметра

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

не, прям зашел в папку а там 50 мелких классов по 2 параметра

почитай про high cohesion и low coupling для начала

ну, я понял вашу позицию

и попробуй спроецировать прочитанное на свой опыт

к сведению принял )

ну, я понял вашу позицию

сомневаюсь что понял

не, прям зашел в папку а там 50 мелких классов по 2 параметра

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

не сомневайся. нельзя сомневаться )

не сомневайся. нельзя сомневаться )

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