Пример асинхронного кода на php с созданием дочернего процесса
из родительского.
Атрибуты в PHP простое объяснение
Попробуем разобраться в:
Что из себя представляют атрибуты
Какие преимущества от использования атрибутов
Напишем парочку примеров.
Настройка Nginx + PHP-FPM
Минимальная настройка файла nginx.conf (default.conf) для php-fpm
Читать далее Настройка Nginx + PHP-FPM
Базовый докер файл (Based Dockerfile) PHP-FPM + xDebug + Composer
Минимальные настройки для Docker + PHP-FPM
Читать далее Базовый докер файл (Based Dockerfile) PHP-FPM + xDebug + Composer
Настройка xDebug php Docker — PhpStorm (2021)
Каждый раз когда нужно заняться качественным дебагом, каждый раз вспоминаю, как настроить xdebug. Но в этот раз нужно было настроить его через «внешний» интерпретатор PHP, который находился внутри контейнера Docker. Читать далее Настройка xDebug php Docker — PhpStorm (2021)
Пример асинхронного выполнения блока кода на PHP
Снова заметка с тупым и самым простейшим примером
Читать далее Пример асинхронного выполнения блока кода на PHP
EventDispatcher
Данный компонент, предназначен для взаимодействия компонентов между друг другом не напрямую, а через посредника EventDispatcher
Представлю очень грубый пример реализации:
Пятая буква D в SOLID
Ну и этот принцип, называемый Dependency Inversion приказывает нам зависеть от абстракции, а не от конкретной реализации. Обратимся снова к первой букве, и посмотрим на класс InstagramParser. В конструкторе класса легко видеть, что там нет требования к конкретным реализациям, есть только требование абстракции, то есть реализации данного интерфейса.
Поэтому на вход может подойди любой класс который реализует интерфейс, как например в первом аргументе конструктора InstagramParser с типом IResource.
Как нарушить данный принцип? Укажем в конструкторе InstagramParser конкретную реализацию, например наследника InstagramResource класс ByHastagResource. Вот и все, зависимость получится очень жесткой, как бы опять прибили гвоздями.
Четвертая буква I из SOLID
Принцип разделения интерфейса.
Вспоминая о зонах ответственности каждого отдельного класса, где стараешься соблюдать принцип решения только одной задачи возложенной на класс. Этот принцип называемый —
Принцип разделения интерфейса обозначает тоже самое.
То есть, допустим, если опять же рассматривать
первую букву из SOLID то мы увидим что мы не создали интерфейс который заставил бы класс, реализовать как getResource() так и метод handle(). А конкретно разбили зоны ответственности + к нему интерфейс, получилось — ничего лишнего.
Получение ресурса и что с ним делать никак не связаны, так и не должно быть никаких причин, заставлять класс реализовывать эти две несвязные вещи через объявленный интерфейс.
Много где можно заметить нарушение этого принципа, где вместо реализации метода интерфейса остаются заглушки, метод с пустым телом либо возвращающий null, false, true чисто для заглушки. Вот это и есть немного плохой пример. Но рефакторинг никто не отменял
Третья буква L из SOLID
Самый непонятный принцип на первый взгляд. О чем он говорит?
- Предварительные условия не могут быть усилены в подтипе.
- Постусловия не могут быть ослаблены в подтипе.
- Инварианты супертипа могут быть сохранены в подтипе.
С ума можно сойти, о чем тут речь?
Читать далее Третья буква L из SOLID