Comments 15
Функционал Reflection, конечно, интересная вещь. Жалко что места в реальных проектах ему места практически нету(кроме довольно специфических задач, в т.ч. описанных в статье)
В коде приложения, скорее всего, таким заниматься не надо (ну, разве что колхозишь какой-то свой велосипед).
В коде же фреймворков и библиотек может встречаться довольно часто.
Допустим, PHP-DI активно использует рефлексию для реализации автосвязывания (когда DI контейнер по сигнатуре конструктора сам определяет, что в него надо внедрять).
Или Doctrine — на основе описания модели (обычный PHP класс со специальными phpdoc-аннотациями) генерирует sql-скрипты.
Тот же phpunit — разработчик пишет тестовый класс в соответствии с определенными соглашениями (имена методов, phpdoc-аннотации), а тестовый фреймворк через рефлексию определяет, что и как в этом тесте надо запускать.
Никто же пока не отменял контексты:
$result = (function () {
return $this->somePrivateMethod();
})->call($context);
$closureBind = Closure::bind(function &(SomeClass $someClass) {
return $someClass->privateProperty;
}, null, $someClass);
$privateProperty = &$closureBind($someClass);
$privateProperty в данном случае будет содержать ссылку на приватное свойство, которое можем смотреть и изменять. Работает, к слову, быстрее рефлекции.
Принципиально не тестирую приватные методы. Тестирую публичный интерфейс.
Если что-то приватное очень хочется протестировать, скорее всего, это означает, что эта приватная логика — сама по себе отдельная ответственность. И выносится в отдельный класс (в соответствии с SRP).
Запрос: site.ru/post/1
В маршрутах написано правило 'post/{post}'
Action в контроллере тебе уже не нужно делать запрос, и определять класс Request, оба параметры будут распознаны Reflection API и переданы:
public function show(Post $post, Request $request)
{
// $post === Post::where('id', 1)->first();
}
Введение в PHP Reflection API