Решил сравнить скорость выполнения call_user_func_array() с обычным вызовом функций на разных версиях PHP и последним HHVM. Весь код измерения времени я запускал на 3v4l.org и фиксировал результаты в сводные таблицы. За основу взял функцию array_merge() с массивом MIME-типов и 1 млн раз вызывал её в цикле разными способами.

Код выше сравнивает скорость выполнения функции array_merge() с её вызовом через call_user_func_array(). Как видно, в седьмых версиях PHP нет никакой разницы по времени выполнения, а вот HHVM 3.22.0 остался на уровне PHP 5.6.30, хотя немного быстрее:

В PHP 7.*.* провели хорошую оптимизацию и при вызове функций можно не задумываться об производительности call_user_func_array(). Это касается и вызова самописных функций и методов вызываемых из класса.

Замеры скорости получились следующие:

В PHP 5.6.30 и HHVM 3.22.0 видно большую разницу при разных способах вызова функций, а в PHP 7.* как бы вы функцию не вызывали, её время выполнения будет примерно на одном уровне. Проще говоря, в последних версиях PHP вызов функций через call_user_func_array() и её исходных вариантах не имеет разницы.

Недавно задался вопросом: что такое ликвидность знаний? Могут ли знания быть ликвидными и если могут, то о какой ликвидности идёт речь? Сразу сходу я сгенерировал следующие варианты определения термина «ликвидность знаний»:

а спрос на знания;
б возможность человека применять полученные знания;
в место и время, когда уместно использовать определённые знания.

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

Новое определение мне далось не сразу.

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

Вы смотрели фильм Марсианин с Меттом Деймоном? Оказавшись на другой планете в одиночку, да ещё без интернета, астронавт Марк Уотни смог с помощью своих знаний противостоять сверхсложным проблемам, к которым никто не готов даже на Земле и с интернетом. Он налету синтезирует новые знания и сразу применяет их, чтобы решить свою проблему —
выжить. Посмотрите этот фильм, чтобы понять о чём я тут говорю.

Вашему внимание представляю перевод статьи Goodbye controllers, hello request handlers от Jens Segers, который опубликовал её в своём блоге. Если переводить буквально, то статья в русском переводе должна называться «Прощайте контроллеры, да здравствуют обработчики запросов», но я решил назвать её проще — «Обработчики запросов вместо контроллеров». Вся статья сводится к тому, что все действия контроллеров нужно выносить в отдельные исполняемые классы. Как, зачем и почему читайте ниже.

За последние годы в ландшафте PHP многое изменилось. Мы стали использовать больше паттернов программирования и таких принципов, как DRY и SOLID. Но почему мы всё ещё используем контроллеры?

Если вам доводилось работать над большими приложениями, возможно, вы заметили, что рано или поздно контроллеры становятся толстыми. Даже при внедрении репозиториев или сервисов в контроллеры, со временем количество зависимостей, методов и строк кода неизбежно растёт.

Позвольте представить вам обработчики запросов (request handlers). Концепция очень проста, но малоизвестна среди PHP-разработчиков. Обработчик запроса является контроллером, но ограничен одним действием. Эта концепция очень похожа на шаблон Action-Domain-Responder, предложенная Paul M. Jones, альтернативой шаблону MVC, которая фокусируется на более «чистых» запросах и ответах (request-response) для веб-приложений.

Хороший способ создания обработчиков запросов — использование вызываемых классов. Вызываемые классы — это классы, которые используют магический метод __invoke() в PHP, превращая их в исполняемые, что позволяет из класса сделать функцию. Вот простой пример вызываемого класса:

<?php

class Greeting
{
    public function __invoke($name)
    {
        echo 'Hello ' . $name;
    }
}

$welcome = new Greeting();

// Hello John Doe
$welcome('John Doe');

На данный момент вы, скорее всего, спрашиваете себя: «Зачем мне это нужно?». Это имеет смысл при ожидании маршрутизатором callback-функций или конкретных зависимостей. Проще говоря, не нужно парсить строку и разбивать её на контроллер и метод. Вы можете сразу указать свою зависимость из http-слоя. Посмотрите наглядный пример, как обработчики запросов уже сейчас можно регистрировать в Laravel или Slim:

<?php

Route::get('/{name}', Greeting::class);

А теперь сравните это с тем, что обычно происходит в ваших проектах:

<?php

Route::get('/{name}', 'SomeController@greeting');

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

Принцип единственной ответственности

На мой взгляд, контроллеры со многими видами действий нарушают принцип единственной ответственности (SRP) из SOLID. Обработчики запросов, наоборот, решают эту проблему через разделение методов контроллеров на свои собственные независимые классы, что упрощает их обслуживание, рефакторинг и тестирование.

Ниже приведен пример двух обработчиков запросов, которые вынесены из двух методов, вшитых в UserController (редактирование и обновление данных пользователя):

<?php

class EditUserHandler
{
    public function __construct(
        UserRepository $repository,
        Twig $twig
    ) {
        /* ... */
    }

    public function __invoke(Request $request, Response $response)
    {
        /* ... */
    }
}

class UpdateUserHandler
{
    public function __construct(
        UserRepository $repository,
        UpdateUserValidator $validator,
        ImageManager $resizer,
        Filesystem $storage
    ) {
        /* ... */
    }

    public function __invoke(Request $request, Response $response)
    {
        /* ... */
    }
}

Это подводит нас к следующему преимуществу.

Тестируемость

Как давно вы писали модульные тесты для своих контроллеров? Вероятно, вы закончили созданием смешанных зависимостей, которые даже не были связаны с вашим тестом. Поскольку обработчики запросов разделяют различные действия контроллера на отдельные классы, вам нужно только вводить или связывать mock-объекты для конкретного действия.

Недавно Jeffrey Way в своём Твиттере дал совет по тестированию: сделайте свои классы тестов как можно более конкретными, а затем используйте каждый тест для описания важного правила/способности (rule/ability).

Testing Tip: Make your feature test classes as specific as possible, and then use each test to describe an important rule/ability. pic.twitter.com/SaIwonVkIC

— Laracasts (@laracasts) August 5, 2017

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

Рефакторинг

В современных IDE есть мощные варианты рефакторинга. Но если вы привязываете методы контроллеров к маршрутам в конфигурационных файлах (например, Laravel или Slim), то вы сталкнётесь с проблемой замены старых вызовов (строчных) на название объектов. Ничего не поделать. Вот так должно выглядеть:

<?php

Route::get('/{name}', Greeting::class);

И это намного проще, чем такой вариант:

<?php

Route::get('/{name}', 'SomeController@greeting');

Вывод

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

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

1) Porto (Software Architectural Pattern)
   https://github.com/Mahmoudz/Porto

2) Action-Domain-Responder
   https://github.com/pmjones/adr

3) Request-Driven Development
   http://martinbean.co.uk/blog/2017/01/05/request-driven-development/

4) Classes vs. Namespaces
   http://antonkril.github.io/classes-vs-namespaces

Ко мне часто обращаются за помощью в программировании: найти ошибку, подсказать решение, написать скрипт и тому подобное. В основном это друзья, читатели блога или люди пришедшие с поиска на мои статьи. Они задают вопросы двух типов: 1) ответ, который помещается в комментарий; 2) ответ, который не помещается в комментарий. На первый тип вопросов я отвечаю сразу, будь то это почта или комментарий в блоге.

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

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

PHP позволяет хранить временные данные в ОЗУ или файлах. Это реализовано с помощью потоков чтения-записи php://memory и php://temp, которые можно открыть через fopen() и управлять данными в файлоподобной обёртке до завершения скрипта. После окончания работы PHP уничтожит все временные данные, если их намеренно не сохранить. Куда записать временные данные:

Способ                 Описание
————————————————————————————————————————————————————————————————————————————————————
php://memory           Записывает и всегда хранит данные в ОЗУ. С помощью fopen()
                       можно работать как с обычным файлом. Сохранить данные можно
                       копированием в другой поток stream_copy_to_stream() или
                       передачей контента stream_get_contents() в другой обработчик.

php://temp             Создаёт файл во временной папке, когда размер данных
                       превышает 2 Мбайт. До этого все записанные данные
                       хранятся в ОЗУ. Временная папка определяется аналогично
                       функции sys_get_temp_dir().

php://temp/maxmemory:0 Обнуляет максимальный размер данных в байтах для хранения
                       в памяти и с первым байтом создаёт файл во временной папке.
                       Можно установить свой лимит стартового хранения данных в
                       ОЗУ путем добавления /maxmemory:NN, где NN — это
                       максимальный размер данных в байтах для хранения в памяти
                       перед использованием временного файла.

tmpfile()              Создаёт временный файл с уникальным именем в режиме
                       чтения и записи r+, а затем возвращает файловый указатель.
                       Ничем не отличается от php://temp/maxmemory:0, кроме
                       способа вызова. URI временного файла можно получить
                       с помощью функции stream_get_meta_data() и сохранить данные
                       через копирование файла copy() по URI.

Все временные файлы автоматически удаляются, а ОЗУ очищается после завершения скрипта. php://memory и php://temp нельзя будет переиспользовать, т. к. после закрытия потоков невозможно сослаться на них. Как правило, сохранность временных данных, по необходимости, достигается путём копирования. Ниже привожу два примера, которые демонстрируют работу со временными данными:

<?php

///////
// 1 //
///////

// Откроем поток php://memory
$temp_data = fopen('php://memory', 'w+');

// Запишем "Hello, world!"
fwrite($temp_data, 'Hello, world!');

// Извлечём метаданные из потока
stream_get_meta_data($temp_data);

// Array
// (
//     [timed_out]    => false
//     [blocked]      => true
//     [eof]          => false
//     [wrapper_type] => PHP
//     [stream_type]  => MEMORY
//     [mode]         => w+b
//     [unread_bytes] => 0
//     [seekable]     => true
//     [uri]          => php://memory
// )

// Сбросим курсор
rewind($temp_data);

// Получим "Hello, world!"
stream_get_contents($temp_data);

// Создадим новый файл data.txt
$fh = fopen('data.txt', 'w+');

// Сбросим курсор ещё раз
rewind($temp_data);

// Сохраним временные данные в новый файл
stream_copy_to_stream($temp_data, $fh);

// Закроем ресурс файла data.txt
fclose($fh);

// Закрывать поток php://memory необязательно, т. к. все данные
// будут автоматически уничтожены по завершению скрипта.
// fclose($temp_data);


///////
// 2 //
///////

// Создадим временный файл
$tmpfile = tmpfile();

// Запишем "Hello, world!"
fwrite($tmpfile, 'Hello, world!');

// Извлечём метаданные из потока
stream_get_meta_data($tmpfile);

// Array
// (
//     [timed_out]    => false
//     [blocked]      => true
//     [eof]          => false
//     [wrapper_type] => plainfile
//     [stream_type]  => STDIO
//     [mode]         => r+b
//     [unread_bytes] => 0
//     [seekable]     => true
//     [uri]          => home\user\temp\phpDC08.tmp
// )

// Получаем URI временного файла
$uri = stream_get_meta_data($tmpfile)['uri'];

// Сохраним "Hello, world!" в файл data.txt
copy($uri, 'data.txt');

// Временный файл будет автоматически удалён по завершению
// скрипта. Закрывать открытый дескриптор необязательно.
// fclose($tmpfile);