Laravel: Как создать функцию хелпер
Хелперы могут быть полезны в ваших Laravel проектах. Они помогают упростить код в проекте простым и понятным способом. В Laravel есть множество встроенных хелперов.
В Laravel уже есть множество встроенных хелперов, таких, как dd() , abort() и session() . Но по мере роста проекта вы обнаружите потребность в собственных хелперах. В этой статье мы рассмотрим, как создавать и использовать наши собственные вспомогательные PHP функции в Laravel.
Создание функции хелпера
Создание собственного хелпера необходимо начать с создания нового PHP файла, в котором он будет размещён. Давайте создадим файл helpers.php в каталоге app нашего приложения. Кстати, его расположение зависит от личных предпочтений. Ещё одно место, где размещают этот файл — app/Helpers/helpers.php . Вам нужно выбрать каталог, который, по вашему мнению, лучше всего подходит.
Теперь, когда у нас есть файл, мы можем добавить к нему наш хелпер (вспомогательную функцию). В качестве примера для этой статьи мы создадим супер простую функцию, которая преобразует секунды в часы.
Создадим вспомогательную функцию в нашем helper.php :
if (! function_exists('seconds_to_hours'))
function seconds_to_hours(int $seconds): float
return $seconds / 3600;
>
> Как видно из примера наш хелпер — довольно простая функция. Однако, вы можете заметить одну вещь: имя функции написано в snake case/змеином регистре ( seconds_to_hours ), а не в camel case/верблюжьем регистре ( secondsToHours ), как вы обычно указываете имена классов. Вам необязательно использовать snake case для имени хелпера, но все хелперы Laravel написаны именно так. Советую использовать этот формат, что бы следовать стандарту. Но это полностью зависит от вас.
Ещё одна вещь, которую вы могли заметить — это то, что мы заключили имя функции в if . Это сделано для того, что бы мы случайно не переопределили уже зарегистрированный хелпер с таким же именем. Например, мы использовали пакет, в котором уже была зарегистрирована функция seconds_to_hours() , это помешало бы нам зарегистрировать нашу собственную функцию с таким же именем. Для решения этого конфликта, мы можем переименовать нашу функцию.
При создании вспомогательных функций важно помнить, что они должны использоваться только как хелперы. На самом деле они не предназначены для выполнения какой-либо бизнес-логики, а скорее для того, что бы привести в порядок ваш код. Конечно, вы можете добавлять к ним сложную логику. Но я бы посоветовал подумать о том, что не будет ли этот код смотреться лучше в другом месте. Таком как сервисный класс, action класс или trait.
Регистрация хелпера/вспомогательной функции
Когда мы создали хелпер, необходимо зарегистрировать его, что бы воспользоваться новой функцией. Для этого, мы можем обновить наш composer.json , чтобы файл загружался во время каждого запроса и был доступен для использования. Это возможно потому, что Laravel включает загрузчик классов composer в файле public/index.php .
В вашем файле composer.json есть раздел autoload который выглядит примерно так:
"autoload":
"psr-4":
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
>
>,В этом разделе нужно добавить следующие строки, что бы composer знал, что вы хотите загрузить свой файл:
Раздел autoload вашего файла composer.json теперь должен выглядеть так:
"autoload":
"files": [
"app/helpers.php"
],
"psr-4":
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
>
>,После того как мы в ручную обновили composer.json нам необходимо выполнить следующую команду, что бы выгрузить наш файл автозагрузки и создать новый:
Использование хелпера
Поздравляю! Ваш хелпер должен быть полностью настроен и готов к использованию. Что бы использовать его, вы можете просто вставить в код:
Поскольку он зарегистрирован как глобальная функция, вы можете использовать его в контроллерах, сервисных классах и даже других хелперах. Что мне больше всего нравиться в хелперах, это возможность использовать их в шаблонах Blade. Например, у нас есть класс TimeServiceClass , содержащий метод secondsToHours() , выполняющий то же самое, что и наша вспомогательная функция. Если бы мы использовали сервисный класс в нашем шаблоне Blade, нам, пришлось бы сделать что-то вроде этого:
\App\Services\TimeService::secondsToHours(331) >>Как вы понимаете, если бы это использовалось в нескольких местах на странице, то сильно бы ухудшило визуальное восприятие кода шаблона.
Идём дальше
Узнав как можно регистрировать хелперы, мы рассмотрим ещё один шаг вперёд. По мере роста ваших Laravel проектов, вы обнаружите, что у вас большое количество вспомогательных функций, которые находятся в одном файле. Как вы понимаете, этот файл будет выглядеть неорганизованно. Нам следует подумать о разделении наших хелперов на отдельные файлы.
Представим, что у нас множество хелперов в файле app/helpers.php ; некоторые из них связаны с деньгами, некоторые со временем, а не которые с пользовательскими настройками. Мы могли бы начать разделение этих функций на отдельные файлы, такие как: app/Helpers/money.php , app/Helpers/time.php и app/Helpers/settings.php . Значит мы можем удалить наш файл app/helpers.php , потому что он не нужен.
После этого нам нужно обновить наш composer.json так же, как и раньше, но загружая 3 новых файла:
"autoload":
"files": [
"app/Helpers/money.php",
"app/Helpers/settings.php",
"app/Helpers/time.php",
],
"psr-4":
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
>
>,Не забывайте сбрасывать дамп автозагрузки composer выполняя следующую команду:
Вы можете продолжать использовать свои хелперы, и у вас есть возможность разбивать их на логически разделённые файлы.
Вывод
Надеюсь, эта статья показала вам, как создавать свои хелперы/вспомогательные функции PHP для ваших проектов Laravel. Помните, что не следует их использовать для сложной бизнес-логики и следует рассматривать, как возможность упорядочить вспомогательные фрагменты кода.
Какие есть варианты реализации класса-хелпера для PHP?
В моем приложении на PHP нужно использовать несколько простых функций, которые понадобится вызывать в любых местах приложения. Как это лучше реализовать с точки зрения соответствия принципам ООП? Ребят, примеры кода или примеры реализации приводите, пожалуйста.
сложно рассуждать не имея представления о функциях.
вообще использование хелперов не есть хорошая практика с точки зрения ООП. Поэтому если есть возможность избежать создания хелпера — лучше это делать. Ну а если избежать нет возможности (например у Вас хелпер обеспечивающий дополнительные функции обработки массивов) тогда обычным классом с приватным конструктором и статическими методами.
Я могу конкретизировать, если это поможет.
Вот такие небольшие функции будут массово использоваться повсеместно в приложении.
В похожем проекте ребята используют и глобальные функции и класс Utils с статическими методами на борту. Равняться на них не хочу. Хочу элегантный код.
Avtomat, а зачем обычными? класс будет хранить состояния? нет, хелперы не хранят состояния . нужна возможность создания нескольких экземпляров класса? нет, т.к. хелперы не хранят состояния то и создание экземпляров — избыточная операция. Как бы надобности в обычных методах нет, конечно хелпер можно сделать в виде синглтона, но стоит ли.
Максим Федоров, попробовал сделать не статическими методами, плюс внедрить в контейнер приложения, все стало еще печальнее с точки зрения читабельности и удобства. Так что да, все больше склоняюсь к статическим методам класса Helpers или приложения.
У вас там куча слабо связанных друг с другом вещей собрана в одном месте. Не лучше ли распределить это по разным классам, у каждого из которых будет своя зона ответственности?
Алексей Скобкин, приложение в процессе активной разработки, многое еще буду перекраивать, мелкий функционал без претензий на отдельный класс пока кидаю в хелперы. В первой версии уже сформируется понятная мне самому структура.
zorca, Меня-то убеждать не надо, я с этим не соглашусь. Главное, что вы убедили себя, что обязательно всё приведёте в порядок.
Если это действительно простые функции, то и делать их надо функциями. Композер умеет их подключать в автозагрузку:
zorca, если хотите делать по принципам ООП, то делать с использованием ООП это дело не стоит 🙂 Функции к нему отношения имеют мало
Засорять глобальное пространство более, чем требуется — дурная практика.
Требуется один статический класс-хелпер — никакого смысла дробить его на функции нет, и с точки зрения будущих изменений особенно.
Минус глобальных функций — засорение таки глобального пространства. Хорошо, когда их 5-10, но их число может вырасти и встанет вопрос об упорядочивании вызова таких функций.
Вот именно. И в чем смысл менять шило на мыло? Разница только в возможности напороться на переопределение функции в том же пространстве.
Adamos, ну вообще, все-таки символов меньше. В php ради этого ввели короткую нотацию для массивов.
А переопределить функцию php не даст, а в случае, если функции в одном файле — то тут и ide поможет
BoShurik, и один из простейший способов собрать эти функции в одном файле — это, внезапно, тот самый общий статический класс.
На случай, когда нескольким функциям нужна единая логика, в отрыве от этих функций не существующая (для чего в статическом классе можно просто объявить приватный метод) — тоже что-нибудь предложите?
Adamos, тут конечно класс выигрывает, но это уже не укладывается в описание простых функций, а больше похоже на сервис
Adamos, хотя, можно выделить такие функции во что-то вроде
App\Internal\foo();
чтобы они не мешались в неймспейсе App
Но мне пока такая ситуация не встречалась
Тут как раз наоборот 🙂 ООП используется для того, для чего оно не предназначено. Объект хелпера не инстацировать, все его методы по сути являются обычными функциями, так почему бы их не использовать? Я за семантику
«Статический» класс. Хотя в PHP такого понятия нет, но смысл его в реализации статических методов.
Реализация метода __callStatic, который определит вызовы простых функций, либо переопределит некоторые из них, либо добавит новые (ну например stripos в зависимости от кодировки)
Зачем именно статический можно уточнить? Можно де сделать обычным классом и вызывать методы как обычно.
Avtomat,
А какой смысл от экземпляра?
Если мы делаем ArrayHelper, то экземпляр будет работать с определенным массивом. А функции для работы с массивами могут принимать как один, так и два, так и более. Тот же array_merge к примеру. Или strcasecamp для работы со строками.
Исходя из Вашей логики с экземпляром удобно будет работать, если параметр у реализуемых функций будет один. Будет реализован статический класс BaseArrayHelper, который может работать с несколькими массивами и содержать статические методы, и наследник ArrayHelper, который работает только с одним через экземпляр. Но это уже тема типизации и совсем отходит от темы хелперов. В таком случае придется написать много кода-обертки, чтобы обернуть стандартные функции — такое будет полезно, если только времени вагон.