8+ совершенно бессмысленно вообще везде, кроме энтитей

а начиная с 8.4 вообще за гет/сет надо увольнять)

ну так я в сущностях и использую

это требования инкапсуляции данных

а ты понимаешь что это такое вообще?)

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

да всегда рекомендуют делать через get/set как будут выглядить запросы без этого?

да всегда рекомендуют делать через get/set как будут выглядить запросы без этого?

да никто не рекомендует

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

это и есть инкапсуляция

считай что SRP

да всегда рекомендуют делать через get/set как будут выглядить запросы без этого?

какие запросы?

куда?

обычный круд

круд - это набор операций

я тебе говорю по умолчанию доктрина настроена так что не пропускает запросы без объявленых set/get

запросы... ты про SQL? для чтения используется SELECT

я тебе говорю по умолчанию доктрина настроена так что не пропускает запросы без объявленых set/get

зря говоришь, потому что это чушь)

В Symfony (и в принципе в объектно-ориентированном программировании) использование методов get и set для доступа к данным сущностей является хорошей практикой, и вот почему: Почему использовать get и set методы: Инкапсуляция данных: get и set методы обеспечивают контроль над тем, как данные сущности читаются и изменяются. Это позволяет скрыть внутреннюю реализацию и защитить данные от некорректного использования. Валидация и логика: В методах set можно встроить логику для валидации или преобразования данных перед их установкой. Это может включать проверку допустимых значений, преобразование форматов и т. д. Согласованность данных: С использованием get и set методов вы можете гарантировать, что данные всегда находятся в согласованном состоянии. Вы можете реализовать логику для поддержания целостности данных в одном месте, а не везде по коду. Поддержка ORM и других библиотек: В ORM, таких как Doctrine, методы get и set часто используются для взаимодействия с базой данных. Это позволяет ORM правильно обрабатывать данные и автоматически синхронизировать их с базой данных. Упрощение тестирования: Использование методов доступа упрощает тестирование, так как вы можете легко заменить реализацию геттеров и сеттеров или использовать моки. Гибкость: Если в будущем вам потребуется изменить логику доступа к данным, вы сможете это сделать, изменив только методы get и set, не затрагивая остальной код.

Важно помнить: Автогенерация методов: Некоторые фреймворки или инструменты могут автоматически генерировать методы доступа для ваших сущностей. В этом случае важно проверить, что автоматически сгенерированные методы соответствуют вашим требованиям. Использование публичных свойств: В некоторых случаях, если вы не планируете использовать сложную логику или валидацию, вы можете использовать публичные свойства. Однако это менее гибко и может привести к проблемам с инкапсуляцией. Заключение Использование методов get и set для доступа к данным сущностей является хорошей практикой, так как оно поддерживает принципы инкапсуляции, упрощает управление данными и способствует более чистому и поддерживаемому коду.

1) get/set НЕ обеспечивают инкапсуляции данных, для контроля доступа за ними существуют атрибуты, модификаторы доступа и свойства

2) В энтитю должны приходить уже корректные данные, никакой валидации делать там нельзя, максимум инварианты согласно контрактному программированию, а за валидацию отвечают соответсвующие слои

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

Дальше чушь написана, доктрине посрать на эти гет/сет

С моками, согласен, что упрощает тестирование, т.к. позволяет поломать всё нахрен

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

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

короче, это рекомендация легаси и идеальна для джунов

ну и для тех, кто на пхп 5 сидит

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

у вас на проекте код entity с публичными свойствами?

ты код открывал, не?

я про коммерческий код

там php 8.2, а в нём нет свойств

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

у кого как сделано, частая ли практика отказ от set/get или мне лид мне замечание скажет

там php 8.2, а в нём нет свойств

?

свойства в языке появились в php 8.4 только

бл

так не кто 8.4 не использует ещё

ещё их называют "хуками"

в 8.2 твой код не сработает? без сетеров и гетеров?

ну вот, а поля вполне себе делаю публичными когда надо)

я спросил есть ли на работе практика использования моделей без set/get , а просто публичные свойства

так моделей вообще нет никаких

entity

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

есть такие

наверно #[ORM\Id] #[ORM\GeneratedValue(strategy: 'AUTO')] #[ORM\Column(type: 'bigint')] private ?int $id = null;

ну вот, а поля вполне себе делаю публичными когда надо)

Чем поле от свойства отличается? Это ж одно и тоже по сути

Чем поле от свойства отличается? Это ж одно и тоже по сути

нет же

Как нет? )

property

свойство - это поле с поведением на установку и получение

т.е. get/set методы - это эмуляция свойств в языках, где нет их

свойство - это поле с поведением на установку и получение

Любое поле так или иначе имеет и чтение и установку )

ясно публичные поля используются для entity в проектах?

Любое поле так или иначе имеет и чтение и установку )

в данном случае ты прав, однако тут нюанс

Иначе смысла просто нет. Зачем оно, если мы не сохраняем туда ничего?

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

меня тоже бесит этот переизбыток кода

а с полями надо подумать где надо, а где нет

удалять или нет

Иначе смысла просто нет. Зачем оно, если мы не сохраняем туда ничего?

/** * @var PackageVersionsSet<PackageVersion> * @readonly */ #[ORM\OneToMany(targetEntity: PackageVersion::class, mappedBy: 'package', cascade: ['ALL'], orphanRemoval: true)] #[ORM\OrderBy(['version' => 'DESC', 'createdAt' => 'ASC'])] public Collection $versions { get => PackageVersionsSet::for($this->versions); }

вот жеж

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

Не встречал такой трактовки. Помучаю потом гугел и гпт. М.б. ты и прав.

ясно публичные поля используются для entity в проектах?

редко где, в паре мест всего

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

а зачем?

Не встречал такой трактовки. Помучаю потом гугел и гпт. М.б. ты и прав.

это единственная трактовка, лол)

просто в пыхе поля и свойства почти синонимы, поэтому многие путаются

кто entity покрывает интерфейсами?

это единственная трактовка, лол)

Если можешь быстро пруфануть, велкам 😄 я вот впервые об этом слышу

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

Если можешь быстро пруфануть, велкам 😄 я вот впервые об этом слышу

это поле с гет + сет

так нужно или нет set/get или или и без них нормально работает с публичными полями

ну я же говорил значит в 8.4 наконец то добавили авто свойства из с#

ну я же говорил значит в 8.4 наконец то добавили авто свойства из с#

в шарпах это тоже свойствами просто называется https://learn.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties

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

как и в ЛЮБОМ языке)