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