♻️ Переопределение с помощью интерфейса

Атрибут Override проверяет, что метод действительно переопределяет родительское определение того же метода: это подразумевает, что у класса должен быть родитель, чтобы использовать атрибут Override.

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

Библиотека пхпшника #буст

❓ PDO или ORM?

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

ORM (Eloquent, Doctrine) — путь удобства. Работаете с объектами вместо SQL, код становится чище, а разработка быстрее. Но магия абстракции может привести к неожиданным SQL-запросам, проблемам с производительностью и сложной отладке.

💬 Вы за прозрачность и контроль или удобство и скорость разработки? Какой путь выбираете вы?

Библиотека пхпшника #междусобойчик

Богатые и анемичные сущности в PHP с Doctrine: как правильно структурировать бизнес-логику

Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.

Анемичные сущности:

🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.

🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.

🔸 Этот подход часто используется в приложениях с преобладанием операций CRUD, но может привести к дублированию кода и хрупким архитектурам.

Богатые сущности:

🔹 Богатые сущности инкапсулируют как состояние, так и поведение. Они содержат бизнес-логику внутри самой сущности, что делает код более поддерживаемым, выразительным и легким для тестирования.

🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.

🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).

Преимущества богатых сущностей:

🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.

🔸 Лучшая читаемость кода: API сущности отражает домен (например, $order->pay() вместо $orderService->payOrder()), что делает код более понятным и легче воспринимаемым.

🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.

Статические методы create():

В статье рекомендуется использовать статические методы create() для создания сущностей, чтобы гарантировать их создание в валидном состоянии. Это позволяет избежать создания неполных или некорректных объектов и концентрирует логику инициализации в одном месте.

Сервисный слой против логики сущности:

🔹 Часто бизнес-логику переносят в сервисный слой (например, OrderPaymentService), но это может привести к слабой инкапсуляции и дублированию кода.

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

Когда использовать богатые и когда анемичные сущности:

Богатые сущности идеальны для приложений с сложными бизнес-правилами, которые нужно соблюдать, а также для создания ясной и выразительной доменной модели.

Анемичные сущности могут быть полезны в простых приложениях CRUD или в средах, где бизнес-логика минимальна.

👉 Читать статью

Buggregator — удобная отладка

Buggregator — это идеальный инструмент отладки, который работает как сервер VarDumper, профилировщик Xhprof, локальный SMTP-сервер, локальный Sentry и многое другое.

Ознакомьтесь с постом Павла Бучнева о профилировании PHP (Laravel) приложений с помощью xhprof.

Библиотека пхпшника #инструменты

💻 Подборка новостей по PHP за неделю:​

🔎 Laravel 12.4: Поддержка конвейеров в построителе запросов
Команда Laravel выпустила версию 12.4.0, которая включает метод pipe() для построителя запросов, возможность условного пропуска миграций, метод Arr::sole() и другие улучшения. ​

🔎 Eloquent: Приведение строк к HTML в Laravel 12.4
Начиная с версии 12.4, в Laravel можно автоматически приводить атрибуты Eloquent к HTML-строкам с помощью кастомного класса AsHtmlString. Это позволяет безопасно работать с HTML-содержимым в моделях. ​

🔎 Релизы Symfony 6.4.20 и 7.2.5
Symfony объявил о выходе версий 6.4.20 и 7.2.5, содержащих важные исправления и улучшения. Рекомендуется обновиться до этих версий для обеспечения стабильности и безопасности приложений. ​

🔎 Неделя Symfony #952 (24–30 марта 2025 года)

Библиотека пхпшника #свежак

Как использовать принцип инверсии управления в Laravel? 

​Принцип инверсии управления (Inversion of Control, IoC) в Laravel реализуется с помощью сервис-контейнера, который управляет зависимостями между классами и их внедрением. Это позволяет создавать гибкую и тестируемую архитектуру приложений.

В нашем примере:

Определяется интерфейс PaymentGatewayInterface с методом charge, который должен быть реализован любым платежным шлюзом.

Класс StripePaymentGateway реализует этот интерфейс, предоставляя конкретную логику для обработки платежей через Stripe.

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

В сервис-контейнере Laravel регистрируется связь между PaymentGatewayInterface и его реализацией StripePaymentGateway с помощью метода $app->bind().

Создание экземпляра OrderProcessor осуществляется через сервис-контейнер с помощью метода $app->make(), который автоматически внедрит необходимые зависимости.

Использование IoC в Laravel позволяет:​

🔸 Разделить ответственность между классами, делая их более независимыми и удобными для тестирования.

🔸 Легко заменять реализации зависимостей, например, для использования другого платежного шлюза, достаточно зарегистрировать новую реализацию в контейнере.

🔸 Упрощает тестирование, позволяя подменять реальные реализации зависимостей на заглушки или моки.

PHP под капотом: как работает генерация случайных чисел

Вы когда-нибудь задумывались, как компьютер, эта идеальная детерминированная машина, выполняющая команды с математической точностью, умудряется генерировать «случайные» числа? Ведь в его цифровом мире нет места настоящему хаосу — только чёткие алгоритмы и предсказуемые состояния.

Сегодня мы заглянем под капот PHP и разберёмся, как устроена эта иллюзия случайности!

🔗 Хабр

Метод «skip» у планировщика

Иногда вы можете захотеть пропустить выполнение команды, основываясь на определенном условии. Laravel включает метод «skip» для выполнения этого 🚀

Библиотека пхпшника #буст

🚀 Hypervel — новый фреймворк PHP с нативной поддержкой корутин

Если вам нравится Laravel, но не хватает производительности в I/O-нагруженных проектах — знакомьтесь с Hypervel. Это высокопроизводительный PHP-фреймворк, вдохновлённый Laravel, но построенный на Swoole и с полной поддержкой корутин прямо из коробки. 

🤔 Зачем Hypervel, если есть Laravel Octane?
Octane — это круто, он ускоряет Laravel за счёт долгоживущего процесса. Но вот беда: Octane не умеет в неблокирующий I/O.

Допустим, у вас чат-бот на Laravel, и каждый запрос к ИИ занимает 3–5 секунд. Даже с 10 worker-ами ты не обработаешь 100 параллельных запросов — они просто встанут в очередь. Почему? Потому что все воркеры блокируются на время I/O-операций.

Laravel по своей архитектуре не рассчитан на корутины. И в ближайшем будущем это не изменится.

⚡️ Что умеет Hypervel?
✅ Почти полная совместимость с Laravel API
✅ Корутины — из коробки
✅ QPS в 10+ раз выше Octane (в I/O-нагрузке — в 100+ раз)
✅ Поддержка object/connection pool (DB, Redis, HTTP и др.)
✅ Корутинная обработка очередей и cron-задач
✅ Кеши, очереди, блокировки — совместимы с Laravel
✅ Подходит для микросервисов, API-шлюзов, высоконагруженных систем

🧵 Корутины — главная фишка
Корутина — это как функция, которая может «поставиться на паузу», пока идёт I/O (запрос к БД, файл, сеть), и не блокировать весь процесс. Hypervel использует Swoole, где всё работает на корутинах: HTTP, DB, Redis, файлы и даже стандартные функции PHP.

💡 Один процесс в Hypervel может обрабатывать сотни задач параллельно — без запуска 100+ воркеров.

📊 Бенчмарки
Hello World (без I/O): Hypervel в 10 раз быстрее Octane

Симуляция I/O (sleep 1 сек): Hypervel в сотни раз быстрее


👉 Читать статью