Объявление свойств в конструкторе [перевод]

Larry Garfield пишет отличную серию статей о том, что из себя представляет PHP 8: о скорости, атрибутах, свойствах в конструкторе и многом другом. Сегодня посмотрим на его статью о объявляемых в конструкторе свойствах.

https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/

Возможно, наиболее существенное улучшение PHP 8, в плане удобства разработки, это объявление свойств в конструкторе. Синтаксис в основном заимствован из Hack — PHP-форка от Facebook, но похожий синтаксис используется и в других языках, например TypeScript или Kotlin.

Сразу приведу простой пример. Рассмотрим типичный класс в современном приложении:

class FormRenderer
{
    private ThemeSystem $theme;
    private UserRepository $users;
    private ModuleSystem $modules;

    public function __construct(ThemeSystem $theme, UserRepository $users, ModuleSystem $modules) {
        $this->theme = $theme;
        $this->users = $users;
        $this->modules = $modules;
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Класс имеет 3 зависимости. Название переменной для каждой зависимости повторяется 4 раза: при описании аргумента конструктора, при описании свойства класса, при описании ссылки на свойство внутри конструктора и при инициализации этой ссылки. Получается очень громоздко, и хотя большинство IDE решают такие задачи авто-подстановкой, это всё ещё боль. Я знаю, что многие люди избегают инъекцию зависимостей из-за громоздкого описания.

В PHP 8 вышеописанную запись сократили до:

<?php

class FormRenderer
{
    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Перемещение области видимости свойства в конструктор говорит PHP «Этот параметр — свойство, ты должен назначить ему значение». Эффект во время выполнения точно такой же, как в первом примере, но для такой записи нам потребовалось в 4 раза меньше текста.

Тем не менее, мы всё ещё можем описывать параметры по-старинке, и конструктор, конечно, всё ещё может иметь тело конструктора. В этом примере тело конструктора — пустое, но если нам требуется сделать ещё что-то, помимо инъекции зависимостей, мы можем сделать это в теле конструктора, и это будет выполнено после инициализации свойств:

<?php

class FormRenderer
{
    private User $currentUser;

    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { 
        $this->currentUser = $this->users->getActiveUser();
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Но на практике, большинство классов, которые я писал за последние несколько лет — имели конструктор, где не было ничего кроме инициализации.

Объявление свойств в конструкторе удобно использовать для простых объектов. Простые объекты — это объекты с некоторым количеством свойств и геттеров/сеттеров для этих свойств. Для таких объектов весь класс можно свести к конструктору:

<?php

Class MailMessage
{
    public function __construct(
        public string $to,
        public string $subject,
        public string $from,
        public string $body,
        public array $cc,
        public array $bcc,
        public string $attachmentPath,
    ) {}
}

Для внутреннего (не являющегося частью API) объекта public-свойства вполне могут использоваться. Если же объект является частью API или взаимодействует с какой-либо внешней системой, то свойства нужно инкапсулировать, и добавить методы для работы с ними. В любом случае код станет компактнее и удобнее.

При объявлении свойств в конструкторе нужно учитывать несколько моментов:

  • Определение области видимости применимо только к конструкторам, использование их в любой другой функции приведёт к ошибке;
  • Свойство не может быть объявлено как в конструкторе, так и за его пределами.

Спасибо Никите Попову за этот RFC, хотя поводом послужила моя запись в начале года в этом блоге, так что я требую себе 0.1% 🙂

Мы уже в плотную подошли к релизу PHP 8 и вот-вот сможем увидеть на практике что из себя представляет объявление свойств в конструкторе.

Поиск по триграммам

Этим материалом я открываю серию статей по методам полнотекстовых поисков. Будем разбирать:

  1. Elasticsearch — один из самых востребованных, судя по вакансиям, инструмент. Многое умеет, быстро ищет, поставляется со своим личным стеком утилит. Будем разбираться в следующей статье.
  2. Sphinx. Да-да, он вроде как уже мёртв, а вроде много где используется, хорошо работает, имеет адаптеры под разные языки и фреймворки. Так что — имеет право быть.
  3. Поиск по триграммам — интересный поиск, наименее затратный в плане реализации, и весьма эффективный. Работает благодаря расширению, подключаемому в Postgres. Именно он и будет темой сегодняшней статьи.

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

Читать далее →

Паттерн Transactional outbox

Что может быть сложного в логировании? Создал инстанс какого-нибудь Monolog’а, навтыкал $logger->info() под каждой строчкой, выполнение которой хотелось бы запечатлить в истории, и сиди себе посматривай в журнал. А вдруг где-то будет ошибка, лог не сохранится, а логируем мы данные банковских операций?

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

Читать далее →

Lumen + Docker + Websockets

Image for post

Последнее время работаю с Lumen. Lumen — это урезанная версия Laravel, аля symfony-skeleton для Symfony. По этой причине большинство решений, описанных для Laravel-систем, к Lumen’у прикрутить бывает сложно, а что-то и совсем невозможно, без переопределения vendor-пакетов.

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

Читать далее →

PHP + Go = ♥ или RoadRunner в действии

Привет.

Много раз уже слышал о RoadRunner — сервер веб-приложений, написанный на Go. Думаю, настало время пощупать, что это такое.

Проблема

PHP работает по простому принципу — один запрос — один процесс. Мы открываем страницу — на сервер уходит запрос. Где-то на сервере есть стек с горячими PHP-FPM процессами, один из которых выделяется и обрабатывает пришедший запрос. Отдав ответ — процесс выгружает все данные из памяти, очищает своё состояние и умирает. Это, я думаю, одна из вещей, почему многие не любят PHP. И правда, при растущих нагрузках рост процессов — неприятный удар по производительности, часто требующий пересмотра архитектуры, масштабирования и редкий поглядываний в сторону потоков, когда разработчик внезапно узнаёт, что они есть в PHP.

Читать далее →

Пишем CRUD на Symfony 4

Первым делом, расскажу о том, что такое CRUD и зачем нам это вообще нужно.

CRUD — это аббревиатура по первым буквам этого слова. Каждая из которых имеет своё обозначение:

  • С — create
  • R — read
  • U — update
  • D — delete

По сути, это просто набор базовых операций над некоторой таблицей в базе данных.

В symfony, мы пользуемся ORM(Object-Relational Mapping), которая скрывает от нас работу с таблицей напрямую, и позволяет работать с нашей базой по правилам ООП. Поэтому, в symfony приложениях мы, как правило, не работаем напрямую с нашей базой, а работаем с объектами.

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

Для начала нам нужно развернуть наше приложение, и обернуть его в докер.

Для этого:

mkdir crud
cd crud/
composer create-project symfony/skeleton crud

Заходим в наше приложение, и создаём папку, называем её docker, в неё кладём содержимое этого репозитория: https://github.com/ko4a/dockerFiles

После этого вытащите файл docker-compose.yml из папки docker, и положите её в общую директорию проекта.

Читать далее →

Создание autoselect-компонента на Symfony/Vue. Часть 2.

Сегодня зафиналим наш autoselect-компонент. Но для начала расскажу, где я был: дорабатывал положенные 2 недели на старой работе и готовился к выходу на новую. Больше пока сказать не могу, кроме того, что компания большая, требуют там больше и работать надо будет упорно, чтобы пройти испытательный. Зато буду больше писать о всяком. А теперь к нашим баранам. В первой части мы немного затронули Vue, написали первый компонент и закончили на этом. Сегодня так просто отделаться не получится — будет и бэк, и фронт, и интересные либы и много нового материала.

Для начала нужно мОкнуть данные с бэка. Что такое мокнуть? Это значит подделать (получить фэйковые данные для тестов). С этими данными будет работать наш компонент, написанный в 1-ой части.

Чтобы это сделать, нам нужно некоторое количество записей в какой-либо таблице. Я создам таблицу Product, каждая запись в которой будет состоять из 4-х частей: id, название продукта, дата поступления и количество.

Чтобы всё сделать по науке мы познакомимся такой вещью, как фикстуры — классы, которые автоматизируют создание записей и используется для тестов. Я познакомился с этим понятием относительно недавно в одном из манов от symfonycast. Но обо всём по порядку. Сначала установим свежую копию Symfony. Устанавливать буду пакет symfony/skeleton — без дополнительных библиотек. Как это сделать я описывал в одном из первых уроков на канале, там всё максимально подробно и с картинками 🙂 Привожу только листинг:

 
Читать далее →