Какому из PSR не следует Symfony?

Ответ на вопрос о соответствии Symfony стандартам PSR

Прежде всего, важно отметить, что Symfony — один из фреймворков, который наиболее активно придерживается и внедряет стандарты PHP-FIG (PHP Framework Interop Group), известные как PSR (PHP Standards Recommendations). В значительной степени, архитектура и компоненты Symfony построены вокруг этих стандартов.

Основные PSR, которые Symfony поддерживает

Symfony явно соответствует и реализует следующие ключевые PSR:

• PSR-3 (Logger Interface) — Компонент monolog, который часто используется в Symfony, реализует этот интерфейс.
• PSR-4 (Autoloading Standard) — Symfony рекомендует и использует эту стандартную схему автозагрузки классов.
• PSR-6 (Caching Interface) — Symfony Cache компонент поддерживает этот интерфейс.
• PSR-7 (HTTP Message Interfaces) — Компоненты Symfony HTTP Foundation были адаптированы для работы с этими интерфейсами (через адапторы).
• PSR-11 (Container Interface) — Сервисный контейнер Symfony напрямую реализует этот интерфейс (ContainerInterface).
• PSR-14 (Event Dispatcher) — Диспетчер событий Symfony соответствует этому стандарту.
• PSR-18 (HTTP Client) — Symfony HTTP Client реализует этот интерфейс.

Принципиальное отличие или несоответствие

Если говорить о том, какому PSR Symfony в своей основе не следует, то это, скорее, PSR-0 (Autoloading Standard). Однако это не «несоответствие» в негативном смысле, а скорее эволюция и переход на более современный стандарт.

• PSR-0 был первым стандартом автозагрузки, но он имел некоторые ограничения (например, требование преобразования _ в пути к файлам).
• Symfony первоначально поддерживал PSR-0, но с появлением PSR-4 (который более простой и гибкий), фреймворк и его экосистема перешли на использование PSR-4.

Поэтому, если устанавливать пакет Symfony через Composer сегодня, вы увидите, что в composer.json используется PSR-4:

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

Контекст совместимости и адаптации

Важно понимать, что Symfony часто предоставляет адапторы или совместимость с другими PSR, даже если его внутренняя реализация исторически отличается. Например:

• PSR-7 (HTTP Messages) — Symfony HTTP Foundation изначально использовал свои собственные классы Request и Response. Однако фреймворк предоставляет легкие адапторы для преобразования между Symfony и PSR-7 объектами.

// Пример адаптации Symfony Request к PSR-7
use Symfony\Bridge\PsrHttpMessage\Factory\PsrHttpFactory;
use Symfony\Component\HttpFoundation\Request;

$symfonyRequest = Request::create('/api');
$psr7Factory = new PsrHttpFactory(...);
$psr7Request = $psr7Factory->createRequest($symfonyRequest);

• Это позволяет Symfony быть совместимым с экосистемой, которая использует PSR-7 (например, многие middleware и клиенты), без необходимости изменять свою внутреннюю архитектуру.

Суть вопроса

Таким образом, утверждение «Symfony не следует PSR-X» в абсолютном смысле не вполне корректно. Фреймворк активно участвует в PHP-FIG и стремится соответствовать стандартам, где это возможно и целесообразно.

Если искать область, где Symfony не использует PSR как основную, предпочитая собственную, исторически развивавшуюся реализацию, то это, пожалуй:

• Рендеринг шаблонов — Symfony использует собственный Twig (который не соответствует какому-либо PSR, так как стандарта для шаблонизаторов нет), вместо, например, следования каким-то гипотетическим интерфейсам шаблонизаторов.
• Базовая HTTP абстракция (HttpFoundation) — хотя она совместима с PSR-7 через адапторы, внутренне это собственная, очень мощная и устоявшаяся реализация.

Вывод

Symfony не следует PSR-0 (так как он был заменен на PSR-4), но это не является проблемой — это прогресс. В остальном, Symfony является одним из самых PSR-совместимых фреймворков на рынке, часто выступая даже как драйвер для создания и принятия новых стандартов. Его подход — это практическая совместимость и адаптация, где это необходимо для интеграции с широкой PHP-экосистемой, без отказа от своих проверенных и мощных компонентов.