Зачем в обычном проекте может понадобиться использование __invoke?

Question

[Роми]

Я прочитал ответа на подобный же вопрос: Зачем нужен __invoke и когда его нужно использовать? - но как по мне - это и не ответы вовсе, потому что они отвечают на вопрос "Как?", но не отвечают на вопрос "Зачем?".

У меня и раньше этот вопрос возникал, но сейчас возник снова, когда я ковырял Laravel Sanctum. Там Guard вызывается через __invoke.

А в чем тут соль-то? Можно ведь и без __invoke всё сделать?

Зачем нужно использовать лишнюю сущность, если можно ее не использовать?

Хочу понять, потому что - а вдруг это как-то удобно?

Answer 1

[Максим Федоров]

__invoke() метод позволяет превратить объект в функцию, которую мы можем передавать/получать/резовлить через псевдо-тип callable.
Этакий элемент функционального программирования.

Хорошо подходит там, где мы выстраиваем pipe или reduce, для описания которых ФП подход является наиболее выразительным и лаконичным. Не знаком с архитектурой Ларавел, но могу предположить, что для авторизации прорисовывается некоторый пайплайн, где можно выполнять разные пайпы или фильтры для првоерки/валидации или чего-либо именно с таким подходом и это более лаконично...

Пример:

public function add(callable $pipe) {
    //..
}

...

$pipeline = (new Pipeline)
     ->add(fn() => true)
     ->add(fn(bool $enabled) =>'Maks enabled')
     ->add(new MaksHandler()) // тут класс с методом __invoke и работает как анонимка
;

Comments

[Adamos]

Лентюй, классы с интерфейсами не позволят при вызове вписать вместо класса инлайн-функцию.
Другое дело, что все это при желании решается проверкой в том же интерфейсе, класс передан или функция.
Ну и естественно, совместимость портит чистоту архитектуры. Особенно совместимость с такой кашей, как РНР ранних версий.

[Adamos]

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

[Роми]

Максим Федоров спасибо за подробный ответ.

Но я все равно не понял :)

А почему мы просто не можем вызвать

SomeClass::someStaticMethodInsteadInvoke()

в чем именно преимущество Invoke перед обычными методами?

// я просто пытаюсь понять, могу ли я где-то применить Invoke в своих проектах, и главное: нужно ли мне это?))

[Максим Федоров]

Роми,

SomeClass::someStaticMethodInsteadInvoke()

Что за не понятная штука? как этот метод скрестить с типом callable?

[Максим Федоров]

Роми,

я просто пытаюсь понять, могу ли я где-то применить Invoke в своих проектах, и главное: нужно ли мне это?))

Да, можете, например многие пайплайны работают с типом callable
Туда закидывайте функции или объекты-функции

[Vitsliputsli]

Роми,

Но я все равно не понял :)
А почему мы просто не можем вызвать
SomeClass::someStaticMethodInsteadInvoke()
в чем именно преимущество Invoke перед обычными методами?
// я просто пытаюсь понять, могу ли я где-то применить Invoke в своих проектах, и главное: нужно ли мне это?))

Правильно, что не поняли, т.к. вам никто и не ответил.
Совершенно верно, можно просто указать метод, там где тип callable, и разницы нет никакой.
А можно как, выше написал Лентюй, просто вызвать метод класса, а его необходимость описать в интерфейсе без всяких callable вовсе.
Если вы используете ООП, то invoke вам не нужен, оперируйте объектами, а не функциями, и не мутантами вида "объект как функция".

[Роми]

Vitsliputsli, спасибо, я ваш ответ укажу в качестве ответа ))

[Роми]

Vitsliputsli, у меня сразу еще вопрос возник

Если вы используете ООП, то invoke вам не нужен, оперируйте объектами, а не функциями, и не мутантами вида "объект как функция".

а что еще я могу использовать кроме ООП?

Соответственно, упомянутый мной в сабже Laravel Sanctum использует ООП, но они таки туда invoke впендюрили, причем, в самую основу этого пакета - в логику Guard :)

[Максим Федоров]

Роми, ооп или не ооп — invoke не влияет, объекты могут быть процессами, если процессы представлять как объекты... например процесс оплаты, процесс обработки корзины или проверки пра, или экшны реквест/респонса, или валидацию, или пайпы какие-нибудь, или транзакцию в БД,
или много чего еще можно представить как объект-функцию

так что делайте удобные семантичные объекты, которым invoke помогает лаконично описать их

Нет смысла писать так:

class Validator {
     public function validate($data)
}

$validator->validate($obj)

масло масленное, а вот так лаконично

class Validator {
     public function __invoke($data)
}

$validator($obj)

Особенно когда надо вкладывать один в другой, например для разных выражений

$maksHandle($newHandle($innerHandle())) — потрясная гибкость

[Vitsliputsli]

Роми, процедурное, функциональное. Но я имел ввиду другое, если используем ООП, значит ориентироваться должны на объекты, а не на функции.
А давайте посмотрим на этот метод:

Guard

/**
     * Retrieve the authenticated user for the incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return mixed
     */
    public function __invoke(Request $request)
    {
        if ($user = $this->auth->guard(config('sanctum.guard', 'web'))->user()) {
            return $this->supportsTokens($user)
                        ? $user->withAccessToken(new TransientToken)
                        : $user;
        }

        if ($token = $request->bearerToken()) {
            $model = Sanctum::$personalAccessTokenModel;

            $accessToken = $model::findToken($token);

            if (! $accessToken ||
                ($this->expiration &&
                 $accessToken->created_at->lte(now()->subMinutes($this->expiration)))) {
                return;
            }

            return $this->supportsTokens($accessToken->tokenable) ? $accessToken->tokenable->withAccessToken(
                tap($accessToken->forceFill(['last_used_at' => now()]))->save()
            ) : null;
        }
    }

Круто, что есть описание: "Retrieve the authenticated user for the incoming request.", но почему-то return mixed, с чего бы это, если вроде как нам должен быть возвращен user, Почему не return User ?
Внутри еще интересней:

return $accessToken->tokenable->withAccessToken(
                tap($accessToken->forceFill(['last_used_at' => now()]))->save()
            )

Что это? save неожиданно что-то вернет и это будет "authenticated user"? Я бы не сказал, что это очень понятный код, поэтому invoke используется скорее всего просто потому, что автору так нравится.

[Vitsliputsli]

Максим Федоров,

а вот так лаконично
class Validator {
public function __invoke($data)
}

$validator($obj)

а вот так еще лаконичнее:

function validate($data)
validate($obj)

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

[Максим Федоров]

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

[Максим Федоров]

Vitsliputsli, ну на счет кривого кода в Ларавел я соглашусь :)

[Vitsliputsli]

Максим Федоров,

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

Если "масло масленное", то назовите
$validator->process($obj)
да, немного подлиннее, чем
$validator($obj)
но несколько лишних символов, это не та проблема, которую нужно решать путем ввода новой сущности мутанта "объект-функция" и переходом от ООП стиля к процедурному.

По-моему, запись через invoke говорит о том, что нам нужна только функция, и мы не придумали как сделать нормальный объект. Быть может это действительно очень простой объект, а может просто не удачно выбранный. Но в любом случае, расширить его до нормального объекта уже не получится, он так и будет всегда недообъектом.
Да, и введение новых сущностей, когда прекрасно можно обойтись без них, это ненужное усложнение и запутывание кода.

[Максим Федоров]

Vitsliputsli,

от ООП стиля к процедурному

к функциональному, у вас более прцоедурный подход,
плюс передача функциональности по цепочке... это более ООП, чем методы процедурные

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

[Роми]

Максим Федоров спасибо. Похоже, что это тоже ответ, просто я не сразу его понял ))

То есть, имеется в виду, что в обычный метод объекта, при вызове как callable сложно передать аргументы, да? (ну, это я так для себя выразил словами для понятности), а в __invoke оно само передается, так? ))

[Максим Федоров]

Роми, нет, не само — все везде надо явно передавать

[Роми]

Максим Федоров, вот этот код у меня работает:

class MyInvoke
{
    protected $state = 1;

    public function __invoke($arg)
    {
        $this->state++;
        return $arg + $this->state;
    }
}

Route::get('/', function () {
    $arr = [1, 2, 3, 4, 5];
    return var_dump(array_map(new MyInvoke(), $arr));
});

то есть, если бы я вместо invoke попробовал бы использовать обычный метод объекта - мне пришлось бы как-то передавать в этот метод аргумент - но я сходу не нашелся как это сделать.

Можно, конечно, использовать статический метод, но тогда у нас не будет сохраняться состояние callable - а Лентюй написал)) что вся соль именно в сохранении состояния.

[Vitsliputsli]

Максим Федоров, ну где здесь функциональный? Функциональный это совсем другое, это функция в математическом понимании.
Если вы объявляете функцию, а потом ее вызываете - это чистый процедурный подход. Если вы функцию замаскировали под объект, но все равно все работает как в предыдущем предложении - это процедурный подход. Если вы в классе наделали статических функций и вызываете только их - это процедурный подход со странным неймспейсами через классы.

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

Это вам хочется верить, что ответственность одна, потому что у недообъекта только один метод-функция, ответственность абсолютно от этого не зависит, даже в одном методе можно нафигачить все что угодно.
Второе предложение вообще не понял. О каких паттернах идет речь? И что за плюсы и минусы, можно их перечислить?

[Vitsliputsli]

Роми, только, если вы завязались на тип callable и не можете с него слезть.
Т.е. у вас есть метод:
function method(callable $func)
Вы можете создать мутанта $mut и скармливать его:
$class->method($mut)
а можете создать обычный объект Common $obj с методом methodLikeInvoke:
$class->method([$mut,'methodLikeInvoke'])
или так, как вы писали выше:
$class->method('Common::methodLikeInvoke')
Вариант с мутантом, работает, потому как можно сделать так $mut(). Это чистой воды процедурный подход, вы создали функцию и потом ее вызываете, в код случайно затесались какие-то объекты, но это уже не ООП.
Еще раз, если вы используете процедурный подход, то вопросов нет, но если вы пишите с помощью ООП, то все эти функции из процедурщины нужно заменить на нормальные объекты. Чтото вроде такого:

function method(ActionInterface $action) {
    return $action->methodLikeInvoke();
}

Interface ActionInterface 
{
    public function methodLikeInvoke() : bool
}
Class Action implements ActionInterface
{
    public function methodLikeInvoke() { ... }
}

Все, все в рамках ООП, используются объекты, никакой процедурщины, никаких процедурных функций, который нужно маскировать под объекты, никаких процедурных вызовов, контракты описаны, с указанием типов, никаких callable, которые не несет никакой информации о бизнес-объекте, а просто говорят что это функция, т.е. еще одна часть из процедурного подхода.

[Максим Федоров]

Роми,

sandbox.onlinephpfunctions.com/code/397f9095d4a727...

[Максим Федоров]

Vitsliputsli, один из элементов функционального программирваония: функция высшего порядка
Объект с методом __invoke() хорошо имитирует эту концепцию функции высшег опорядка: мы передаем функцию, другой код принимает функцию, может передать дальше или выполнить — это элемент ФП

Городить процедуры у классов — это процедурное. Тут не с обидной коннотацией я выдаю слово процедурное, тк ООП — есть процедурное программирование априори.

Именно в этом и плюс: мы передаем функцию, принимаем функцию... удобства ФП и некоторые паттерны ФП можем использовать безболезненно

Паттерн номер 1: Pipeline Pattern, вполне себе функциональный сам по себе и очень удобный
Пример: https://pipeline.thephpleague.com/usage/

[Роми]

Vitsliputsli, да я же не против :)

Меня эти колбэки еще в JS задрали )))))))))) когда промисов и асинхов не было ))

Я совершенно не идеологизирован в этом смысле - мне чем проще - тем лучше ))

Просто вот в очередной раз наткнувшись в коде на invoke - решил прояснить.

Ибо в моем понимании разработчики Laravel зря огород городить не станут.

Зачем-то же они так сделали...

[Максим Федоров]

Роми, потмоу что удобно, вот и сделали

Можно коллбек передать, можно объект — если можно и так и так, то почему бы не воспользоваться тем, чтобы не городить тот пример, что я вам ссылкой скинул (последний через массив)

Я вам комментариев 10 написал со словом "удобно" и расписал чем именно :) устал уже, если честно

[Максим Федоров]

Роми, ваш опыт в JS эт оваш опыт, но не отменяет, что в системе, где нужны пайпы и редьюсы выразительнее/удобнее/безопаснее работать с ФП подходом

А мы знаем, что такие штуки частенько нужны

Выше скинул ссылку на простенькую либу https://pipeline.thephpleague.com/usage/
Попробуйте переписать столько выразительно для ООП-подхода

[Максим Федоров]

Роми, кстати6 JS хороший пример

Они ушли от коллбеков к промисам, причем это сделали интересно в контексте нашей беседы:
они ввели ОБЪЕКТ Promise для боксинга/анбоксинга, хотя бОльший уклон к ФП-парадигме в языке

Используйте разные стороны разных парадигм :)

[Vitsliputsli]

Максим Федоров, спасибо большое за пример, теперь понятно о чем речь. Да, здесь уже функциональное, но зачем функциональное маскировать под ООП, сделали бы обычными функциями, было бы очевиднее. При процедурном или ООП подходе все выглядело бы еще проще, не проще только, если нужно переиспользование, но и здесь сохранить последовательность шагов не сильно усложнит код. И это я говорю без учета того, что там еще что наверчено внутри класса pipeline.
ООП не процедурное программирование, от слова совсем. Да, в ООП зачастую не обойтись без отдельных процедурных вещей, впрочем как и в функциональном. Так что это заявление бессмысленно. Но в ООП это используется на нижнем уровне, и вы прекрасно можете использовать ООП по назначению - структурировать код. В функциональном не обойтись без процедурного на самом верхнем уровне, потому как структурировать функционально проблематично.
Впрочем, спорить о ООП, функционально и процедурном бессмысленно. Я это уже подчеркивал выше, нравится вам функциональный - используйте, хоть прям внутри метода объекта, но маскировать функциональное программирование под ООП - это странно. А вытаскивать функциональное на верхний уровень параллельно с ООП - опасный подход. И выглядит это прекрасно только в примитивном примере с арифметическими опреациями над одной переменной и засчет отказа от функциональной записи и последовательного применения функций. Как-только будет чтото сложное - начнется ад, никто не пишет DSL функционально, поэтому фича забавная, но не более того.

[Максим Федоров]

Vitsliputsli,

зачем функциональное маскировать под ООП, сделали бы обычными функциями, было бы очевиднее.

Потому что за каждым пайпом может быть не простой объект, а объект из DI-контейнера со сложной стратегией его создания... сам пайплайн может быть элементом сервис-контейнера

Вот так и совмещаем ФП + ООП и живем :) Там где что-то выразительное и удобное — используем, глупо зацикливаться на одном подходе, тем более (по моим убеждениям), заворачивание объекта в функцию не нарушает сам ООП, тк сохраняется абстракция, как главный концепт ООП

[Максим Федоров]

Vitsliputsli, кстати, хорошо что вы DSL упомянули
я делал пару DSL и как раз invoke в одном из примеров (не в обоих) подошел как-нельзя гармонично и здорово

[Vitsliputsli]

Максим Федоров, ну, может я и ретроградствую, время покажет.

А что за DSL? Арифметические вычисления с алгеброй логики? Вызов одиночных функций с параметрами? Или язык с операторами, функциями, условиями и алгеброй логики?

[Максим Федоров]

Vitsliputsli, бищнесовая логика, запрятанная в критерии

[Роми]

Максим Федоров, спасибо :) Видимо этот случай, когда пока сам не попробуешь - не поймешь ))

Answer 2

[Роми]

Ответ от Vitsliputsli

Правильно, что не поняли, т.к. вам никто и не ответил.
Совершенно верно, можно просто указать метод, там где тип callable, и разницы нет никакой.
А можно как, выше написал Лентюй, просто вызвать метод класса, а его необходимость описать в интерфейсе без всяких callable вовсе.
Если вы используете ООП, то invoke вам не нужен, оперируйте объектами, а не функциями, и не мутантами вида "объект как функция".