Алексей Скобкин

1. symfony/validator

$violations = $this->get('validator')->validate($dto);

2. symfony/serializer

$dto = $this->get('serializer')->deserialize(
    $request->getContent(),
    DTO::class
);

Все это можно красиво обернуть в Action Argument Resolving, т.о. код будет выглядеть что-то вроде

public function editAction(DTO $dto)
{

}

где в $dto уже будет валидный объект

Вы сконцентрировались на попытке сделать ваше решение БД-ориентированным, в то время как вас не просили этого делать. Из за БД-ориентированности в вашем коде происходят странные вещи, можно сказать "магия". Некоторые вещи вообще странные, вроде списка статей внутри статьи.
Вас просили сделать описания классов, методов и свойств класса в формате PhpDoc, а вы этого не сделали.

Попробуйте ещё раз, но со следующими ограничениями:

• В классе User оставьте только свойство $name и свойство $articlesList = [] - который будет уже списком статей, которые написал автор. Пусть список храниться внутри объекта пользователя, в ORM типа Doctrine так и происходит. Уберите оттуда $id.
  
• Не забудьте добавить методы getName() и setName($newName) для работы со свойством name. Это является правильным для ООП - не позволять клиентам класса работать со свойствами напрямую, а лишь вызывая методы, которые вы предоставляете. Причина проста - в методе вы можете указать какое-нибудь дополнительное поведение, которое требуется при изменении свойства.
  
• Также придумайте методы, необходимые для работы со списком статей. Ну вот два уже напрашивается из задания: "возможность для автора создать новую статью" и "возможность получить все статьи конкретного пользователя". Но по хорошему статью ещё и удалить можно...
  
• Для статьи вам понадобятся 2 поля - это ссылка на автора (то есть сам объект класса User, а не магический id). То есть $author, и ещё, раз это статья, то ей неплохо бы добавить свойство $text.
  
• А теперь главное - не пишите вообще текста методов. Только открыли фигурные скобки и сразу закройте на следующей строке. От вас этого не просили. И даже явно указали этого не делать!
  

Если всё ещё сомневаетесь, то советую почитать обучалку по Doctrine. Там они постепенно создают совершенно коректные с точки зрения ООП классы User и Bug. (они это делают последовательно, так что не поленитесь докрутить до самого конца обучалки)

Я тут решил сделать $ideya, но я полный 0 в этом. А давайте Вы сделаете.
$ideya - каждый 5 заголовок на тостере

Вы не пробовали брать простые задачи, решение которых Вам приблизительно известно. Что бы при разработке возникали конкретные вопросы на которые можно дать конкретный ответ. Вопросы из разряда "как сделать сайт" получают только такие ответы, как этот.
И дружеский совет - "замутили" сильно пахнет средней школой.

Нет, не так. Суть DI в управлении зависимостями, когда я смотрю конструктор - я должен видеть от чего зависит код. Ваш вариант практически не отличается от использования глобальных переменных/сервис локатора.
Все современные контейнеры позволяют забиндить интерфейс с реализацией, плюс автовайринг. Для вас, как программиста, даже проще сразу инжектить нужные вам классы, чем просить их у контейнера.

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP):
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

В целом это считается плохой практикой. Приведу ссылку на соответствующий кусок из документации DI контейнера в Symfony: https://symfony.com/doc/current/components/depende...

Доставая зависимости непосредственно из контейнера вы лишаете себя массы преимуществ внедрения зависимостей:

• Страдает тестируемость класса т.к. вы не можете подменить сервисы на нужные вам во время тестов
  
• Вы лишаете себя возможности валидации целостности графа зависимостей в случае если используется компилируемый контейнер (как, например, в Symfony)
  
• Вы привносите в класс излишнюю информацию о названиях конкретных сервисов которые вы достаёте из контейнера
  
• Вам потребуется дополнительно проверять есть ли каждый из сервисов в контейнере и что же именно вы достали из контейнера (через instanceof)
  

Уверен что есть и другие факторы, это то что пришло на ум в первую очередь.

Это очень просто. Нужно просто сгенерировать целое число от 0 до 2047 (включительно) и перевести его в двоичную систему счисления.

Вопрос решился.

Как я и предполагал, надо было создать стек отложенных бинарных операций. При добавлении новой бинарной операции в стек, нужно сравнить ее приоритет с приоритетом предыдущей операции, и если новая операция имеет меньший приоритет, то выполнить предыдущую. Со скобками почти то же самое, только там используется флаг.

Если будет возможность, выложу решение на GitHub.

Всем спасибо за помощь!

Один из вариантов решения: https://t.me/litreevsays/1164