Твои же за АПИ?

1. это перевод 2. прошло 5 лет

надо бы пометить статью что "подход устарел"

http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html вот егор с такими заявлениями выступает на профильных конференциях, и они не очень то заходят. у народа появляется много вопросов на которые сложно ответить и в принципе пригорает у людей)

ну вот да

потому и говорю - Whole Value

надо за это топить

и можно подходить с позиции проблемы

начинается все с того что "геттеры сеттеры это плохо", а как быть с DTO, VO? - и тут шок "это тоже плохо"

вернуть данные из обьекта - плохо

и так до клиники

начинается все с того что "геттеры сеттеры это плохо", а как быть с DTO, VO? - и тут шок "это тоже плохо"

DTO имутабельны, да и геттеры там не особо нужны. VO - там не нужны ни геттеры ни сеттеры

вернуть данные из обьекта - плохо

так стой

секундочку

DTO имутабельны, да и геттеры там не особо нужны. VO - там не нужны ни геттеры ни сеттеры

в пхп геттеры/сеттеры тебе дают 2 вещи. 1 - проверку типов, 2 - ридонли для полей

цитата из драфта "недописанной" статьи на тему "Вам возможно не нужны геттеры и сеттеры" > Перед тем как начать, стоит прояснить один очень важный момент. А именно, что имеется ввиду когда я говорю "сеттер" или "геттер". Под "*сеттером*" и "*геттером*" мы будем подразумевать следующее: *это некая функция/метод, который должен быть вызван для доступа к свойству объекта*.

в пхп геттеры/сеттеры тебе дают 2 вещи. 1 - проверку типов, 2 - ридонли для полей

1. проверку типов мне дает phpstan/phan 2. аналогично. Мне не интересно это в рантайме делать

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

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

и от лишней проверки в рантайме никто не пострадает. хуже когда ее нет

http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html вот егор с такими заявлениями выступает на профильных конференциях, и они не очень то заходят. у народа появляется много вопросов на которые сложно ответить и в принципе пригорает у людей)

вот еще есть такие похожие по радикальности штуки http://verraes.net/2013/04/crud-is-an-anti-pattern/

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

А может замутим какой-нить манифест и запиним его? 1. Это чат про симфони. 2. Это чат ТОЛЬКО про симфони. 3. Если вы хотите обсудить просто пхп, ооп и другие вещи - вам здесь НЕ рады. 4. Если вы хотите задать вопрос, сначала погуглите. 5. Погуглите еще раз, посмотрите документацию соответствующего симфони компонента. 6. Задавайте вопрос. Не здоровайтесь "отдельным" привет, сразу в одном предложении задавайте вопрос. 7. Пользуйтесь Reply чтобы диалог можно было отследить 8. Не согласные могут не пользоваться чатом. Или идут **{тут еще не решил... можно просто оставлю нахуй? }

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

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

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

тесты это 2 секунды максимум времени

тесты это 2 секунды максимум времени

я рад что у тебя это две секунды, у меня это секунд 30, phpstan выполняется так же секунд 30

и поскольку это происходит на CI - меня это не особо парит

сейчас я юзаю phan и он помедленее работает - где-то минуту

но это всеравно быстрее чем проверка в рантайме

и если для тебя это критично - ну ок

я рад что у тебя это две секунды, у меня это секунд 30, phpstan выполняется так же секунд 30

пхпстан выполняется 6 минут щас у нас

пхпстан выполняется 6 минут щас у нас

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

логи)

что логи? логи это способ а не средняя оценка времени

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

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

а это все идет в логи

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

как быстро от момента пуша в гит до момента "попало в логи" у тебя времени проходит?)

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

потому что phpstan?

давай скорее так

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

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

увы у меня не континиус деливери

так что может и неделя пройти

но на стэйджинг - например в течении часа

если кто-то что-то обновляет

но не факт что именно этот кусок системы кто-то будет запускать

и с нужными условиями что бы косяк всплыл

а дев ветки это вообще горячие точки

так

давай совсем по другому

ибо ты свел все в какую-то чернь уже

всякие phpstan и пхпюнит с code coverage запускаются в отдельном неблокирующем джобе на ci

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

давай проще

1. ты пишешь сеттеры в DTO? в VO?

2. нормальные методы в VO/сущностях дают тебе ту же проверку типов?

1. ты пишешь сеттеры в DTO? в VO?

конструкторы

2. нормальные методы в VO/сущностях дают тебе ту же проверку типов?

в смысле?

конструкторы

ну норм, конструкторы я не агитирую не писать, наоборот

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

в смысле?

ну всмысле метод rename(string $name): void тебя устраивает с точки зрения проверкти типов?

сеттеры для DTO (например для форм) - предмет отдельного разговора и тут, в силу ограничений языка, возможно сеттеры норм. Во всяком случае тут главный вопрос зачем ты их написал. Поскольку это DTO - тут все варианты в целом валидны. Согласен?

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

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

иммутабельности нет

ну всмысле метод rename(string $name): void тебя устраивает с точки зрения проверкти типов?

а это к чему?

иммутабельности нет

окей, ты запихнешь это дело в конструктор из формы?

или тебе проще когда форма мэпит на поля (напрямую или через сеттеры)

сеттеры для DTO (например для форм) - предмет отдельного разговора и тут, в силу ограничений языка, возможно сеттеры норм. Во всяком случае тут главный вопрос зачем ты их написал. Поскольку это DTO - тут все варианты в целом валидны. Согласен?

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

ERROR: S client not available

окей, ты запихнешь это дело в конструктор из формы?

если мне нужно, то сделаю свои маппинги для формы

окей, тогда выходит сеттеры для DTO не нужны вообще

(ну и если нужны - это ситуация с компромисами)

устраивает?

а для сущностей сеттеры еще более не нужны

так?

погодь ты с сущностями

окей, для DTO сеттеры нужны? можно ли факт наличия сеттеров для DTO считать компромисным вариантом в силу ущербности php?

дабы не писать мэпперы для каждой формы

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

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

мы сейчас ТОЛЬКО про сеттеры

у DTO в 90% случаев нет сеттеров

давай сначала с ними разберемся ибо с ними проще

у DTO в 90% случаев нет сеттеров

окей

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

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

в случае с DTO ты свою позицию описал и для твоего случая в этом есть очень немало смысла

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

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

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

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

setName($firstName, $lastName) - это сеттер?

ах да, есть еще 3й параметр - плохо если тебя вынуждают писать сеттеры всякие symfony forms, sonata bundle и тд. всегда есть обходные пути

setName($firstName, $lastName) - это сеттер?

нет, это гавеное название метода

нет, это гавеное название метода

окей, setName($name) - это сеттер? или говеное название метода?)

это сеттер

setName($firstName, $lastName) - это сеттер?

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

окей, setName($name) - это сеттер? или говеное название метода?)

и если внутри у тебя $this->name = $name

и если внутри у тебя $this->name = $name

но ты смотришь с позиции интерфейса. ты не знаешь что внутри

в том то и дело

если я вижу setName то я почти уверен что внутри как раз то что я ожидаю

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

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

что значит "что мне не нужно"?