вы сеньор, вы скажите как среди шквала таких вакансий искать то, что нужно...
этакая задача, когда все мы в одних условиях в потоках предложений, но синьоров среди нас — наименьшее число
Мне нужно каждый продукт запросить из микросервиса и записать результат в массив.
Можете еще шире и более детальнее объяснить, почему не запросить товар из Базы напрямую? Что за массив, для чего все?
Может тут и кроется хороший рецепт, когда точно станет понятно, что вы делаете
и все же, работа с состоянием там, где это состояние — лучше и проще, тк эт опросто ежу понятно:
вот данные, вот с ними и работаем... зачем городить аксессоры и выносить работу с состоянием наружу — это как раз наследие кривых подходов из прошлого
датамаппер решил эту проблему, вот мол ` пиши как надо, но нет...
Сеттеры даже в доктриновских энтитях есть и ничего, хвалят как-то умудряются.
В доктриновских сущностях они изибыточно и просто ломают сам паттерн дата-маппера
Создатели дата-маппер специально сделали так, чтобы мы могли делать инкапсулированную логику, а через магию (рефлексию) состояние корректно будет извлечено и загружено в персистенс слой
Документация с сеттерами в симфони — ужаснейший пример, который взяли тысячи разрабов. Это все наследие проблем в джава проектах и большой опыт с AR моделями... Сам окрамиус (соавтор доктрины) в ужасе от такого исспользования сущностей, которое он не хотел
Сеттер — прямое изменение одного поля, прямо, без компромисов, так в названии его здано и так его и используют все
changeProductCollectionAndCalculateTotalPrice() — это логика, там внутри может менять НЕСКОЛЬКО свойств заказа, проверки быть... это полноценный метод с бизнес-логикой, а не сеттинг поля заказа
у меня в примере приведлен пример кода, где тоже меняется стейт платежа... но не это НЕ сеттер, тк напрямую мы не меняем состояние платежа в обхо проверки им самим своего инварианта, все инкапсулировано и объект переходи из состояния в др состояние корректно
setHeaders не имеет смысла, куда ставить? В констурктор реквеста? Методы конфигурации в билдере обычно называются add/with, и мы не напрямую пишем... там проверки могут быть
Set — установить напрямую, в этом суть этого слова
Ну и пример ва очень прост , основная пробелма от сеттеров/геттеров в бизнес-коде
Вы привели процедурный пример, где и массив ок (то есть стурктуры хватает), чем еще раз подчеркнули природу сеттеров — просто замена паблика
..там, где значение переменной важно для какой-либо иной логики в классе.
Иная логика от set (установить значение напрямую) будет отличаться от названия set
Кроме того напрямую к полю иметь доступ иметь плохо, тк все я описал выше... за редким исключением
Frayl, нет ни одного случая... есл иесть сеттер, значит это паблик — нужно просто убрать сеттер и сделать из класса стурктуру, не надо никого обманывать
Пытаюсь подчистить использование оперативной памяти на проде
Но ведь если вы хотите переместить пакет в секцию dev, то на проде код из этих пакетов не юзается... значит он (код) из этих пакетов не влияет на оперативную память ::):):):):):):):)
этакая задача, когда все мы в одних условиях в потоках предложений, но синьоров среди нас — наименьшее число