Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

Обеспечивает предоставление и изменении информации для аутентификации

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

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

Вы правильно рассуждаете, но я бы так мелко не дробил, если мелко раздробить, получится куча объектов, каждый из которых сам по себе ничего толком не может, и пользоваться кучей таких объектов неудобно. Пароль разве не входит в информацию для аутентификации? По моему отдельно «а также» для генерации хеша пароля не нужно. Генерирование хеша это деталь реализации по обработке информации для аутентификации, что входит в представленную обязанность класса User:

Обеспечивает предоставление и изменении информации для аутентификации

P.S. то о чем мы говорим, это задача распределения обязанностей в ООП. Вот это я думаю еще теоретически до конца нерешенный вопрос. У каждого получается так как получается, поэтому столько многолетних дискуссий.

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

А я еще ничего не решил, просто уточняю.

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

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

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

что это не обязанность юзера их генерить

На основании чего так решили?

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

Я использую SL в конструкторе и там же делаю проверку на тип сервиса. Получается почти то же самое, что и настоящий конструктор, только с зависимосью от SL

class Order {

    private $dep;
    
    public function __construct()
   {
       $this->dep = ServiceLocator::instance()->get(Dependency::class);
       \webmozart\Assert::isInstanceOf(Dependency::class, $dep);
   }

}

Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

Во во, я тоже очень много об этом говорил, в т.ч. в комментах на хабре. Даже смешно, когда народ удивляется, что это во многих doctrine-проектах анемичные сущности. Без зависимостей полноценную логику туда не положить, вот и получаются классы с одними геттерами/сеттерами. Кто об этом знает, начинает выходить из положения путем чего-то вроде Order::deliver(Dependecy $dependency), но иногда (не всегда) это то же своего рода раскрытие деталей, нарушение инкапсуляции. Когда у нас есть объект заказа, нас не должно волновать, что он там и как будет проверять, заказ должен знать все о таких проверках сам, тогда будет инкапсуляция.

Какое главное отличие Dependency Injection от Service Locator?

А почему сразу SL — антипаттерн? Если не мешает зависимость от контейнера — SL очень даже юзабельный паттерн, у него свои преимущества есть.

ООП, «святая троица» и SOLID: некоторый минимум знаний о них

Хорошая статья по ООП. В ней в отличие от многих других статей и книг говорится о том, что ООП это способ структурирования программы, без в корне ошибочного «ООП — это парадигма программирования в терминах реального мира».

Топ-65 вопросов по SQL с собеседований, к которым вы должны подготовиться в 2019 году. Часть I

По-моему определение 1NF совсем неправиельно, ну либо переводчик так криво перевел, что смысл потерялся.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

А я не согласен с подобным высказыванием. Слишком идеализировано оно, возведено в абсолют.

Заказчик определяет требования к программе и платит за их реализацию деньги. Разработчикам платят именно за реализацию требований заказчика, а не свои «причуды», которыми они могут наделить программу. Так что то, что внутри программы, ООП, ФП, процедурный код менее важно, чем реализация требований заказчика. У разработчиков может быть сколь угодно идеальная архитектура, паттерны и прочее. но если не реализованы требования заказчика, денег они не получат.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Прям просветили, я до этого таких слов-то не слышал =). Под словом «программисты» я имел ввиду всех людей. которые занимаются разработкой ПО, а не использованием этого ПО. Т.е. я хочу сказать, что потребности потребителей ПО лежат несколько в другой плоскости и им без разницы, что там за «Архитектура» внутри, лишь бы работало, решались бы задачи бизнеса.
P.S. Я честно говоря, вообще ни одного человека еще с должностью «Архитектор ПО» лично не встречал, как правило всё разработчики делают. Вот разделение на фронтенд/бэкенд часто вижу, но чтоб еще и «Архитектор»…

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

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

Так речь о каких требованиях, требованиях закачика к ПО, которые в документах прописываются? Или о всем-всем-всем что все, в том числе разработчики хотят от программы?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Вот это как раз программисты при реализации решают, что и как они будут отделять. Заказчикам, потребителям системы, совершенно без разницы, какая логика и от чего будет отделена. Такие требования от заказчика встретить я думаю нереально.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Никто не говорил. Я пытаюсь показать, что воспринимать ООП как «парадигму программирования в териминах объектов реального мира» некорректно.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Ну вот моделированием каких требований можно объяснить существование в программе класса Контроллера и Сервиса, например?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Программа не должна моделировать требования. Программа должна соответствовать требованиям заказчика (фнукциональным и нефункциональным). А уж какие внутри нее абстракции будут, как она построена, с использованием СУБД или без, с ООП или без это дело разработчиков.
Я тоже раньше думал о том, что в ООП нужно ставить в соответствие программные объекты и объекты реального мира, потом понял, что заблуждался. ООП — это просто способ структурирования программы. Правила такого структурирования для общего случая тоже чисто программные, к реальному миру отношения не имеющие (GRASP, SOLID, low coupling, high cohesion). Да иногда удобно некоторые обекты (как правило для бизнес-логики) именовать и наделять поведением в соответствии с какой-либо сущностью реального мира, но это скорее частный случай. В любой ООП программе полно объектов, которые не имеют никакой связи с реальным миром, всякие фабрики, декораторы, прокси, провайдеры, подключения, мапперы и проч.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

И я не согласен, что ORM содержит идею построить построить в приложении абстрактное хранилище для объектных структур данных

Ладно, скажу так: как только ORM перестает быть шлюзом к БД и начинает быть абстрактным хранилищем объектов — начинается overkill, который не нужен.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Вы говорите про отображение свойств объекта на БД, а я про отображение колонок БД на свойства объектов. Это вещи разные. Отображение колонок на свойства решается просто, отображение объектных структур — задача порой вообще труднорешаемая (сохранение композитов, например).
То что ORM запросы генерирует это само собой. Очевидно, без этого не обойтись. Но ORM это не только генератор запросов, если бы ORM была только генератором запросов, проблем бы не было… Но там есть еще куча всего, а в первую очередь это идея — построить в приложении абстрактное хранилище для объектных структур данных, под которое потом можно подвести реализацию, использующую СУБД. На мой взгляд это тот overkill из-за которого и появляются проблемы. Убрав эту идею, отталкиваясь от БД при работе с данными, мне удается избежать большинства возникающих проблем. С СУБД такое приложение будет работать как клиент, что более естественно, чем подводить базу к приложению как инфраструктуру по сохранению состояния независимых объектных структур.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Я вижу проблему ORM не в попытках поставить в соответствие атрибуты объекта полям в БД, а в построении в приложениях объектных хранилищ на основе репозиториев. У нас уже есть хранилище — СУБД. Интерфейс работы с СУБД — язык запросов. Ну так пусть код приложений и генерирует запросы (sql или qb по вкусу, DAO, можно даже AR, если его воспринимать как удобный способ генерации запросов к отдельным строкам). Сейчас есть много удобных инструментов, чтобы генерировать запросы. Зачем городить свое объектное хранилище, а потом под это объектное хранилище подводить БД? Можно конечно, но по мне так это как-то нерационально, неэкономно, лишний труд. А колонки на свойства отразить — с этим особых проблем нет.