Где в Symfony 3 объявлять глобальные функции(heplers)?

Question

[Владислав]

Где в Symfony 3 можно описывать функции которые будут доступны во всём приложении?

Answer 1

[Андрей Инишев]

На то есть composer
https://getcomposer.org/doc/04-schema.md#files

Comments

[Владислав]

Да, но это как то не круто в composer всё это писать, как будто это не относится к приложению.

Answer 2

[Алексей Павлов]

Сделать папку в корне src, сделать неймспейс, создать класс, в нём сделать статический метод.

<?php
namespace MyFunctions;

class Calc
{
    public static function add($a, $b)
    {
        return $a + $b;
    }
}

<?php
namespace AppBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use MyFunctions\Calc;

class DefaultController extends Controller
{
    /**
     * @Route("/", name="homepage")
     */
    public function indexAction()
    {
        $sum = Calc::add(10, 20);

        return $this->render('default/index.html.twig', array(
            'sum' => $sum,
        ));
    }
}

Comments

[Владислав]

Ну как вариант, я просто думал, что там есть какое то место где это всё можно объявлять. Спасибо!

[Алексей Павлов]

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

[Максим]

Владислав: Старайтесь не делать так. Это нарушает принципы SOLID. Статические методы - всегда неявная зависимость в коде, которая усложняет его тестирование, и делает невозможным моки этой функции.

[Максим]

Владислав: Laravel не является примером хорошей архитектуры, причем здесь Laravel если вы пишите на Symfony. Идеология такая - ты должен создать объект перед тем как его использовать. Чище создать helper в DI контейнере и внедрять его там где нужно, чем иметь этот хелпер в глобальной области видимости. https://phptime.ru/php-features/pochemu-nekotorye-...

[Владислав]

Алексей Павлов: Просто то, о чем я говорю не является как таковым сервисом, представьте, что у вас есть много методов для преобразования строк и их особо не сгруппируешь в какой то определенный класс(сервис), лучше их представить и хранить как обычные функции.

[Алексей Павлов]

Владислав: Максим: Я поясню про моё решение.
Есть три типа функций:
1) Функции используют данные из проекта (из контейнера, из БД, из других сервисов проекта, из других внешних сайтов)
2) Функция является "чистой" - данные приходят только из аргументов этой функции
3) Функция использует как аргументы, так и поля текущего класса (т.е. либо не статические методы, либо использовать статические данные, которые само по себе чаще всего плохо)
Первый тип функции однозначно не стоит делать, как я указал, правильно создать обычный сервис.
Второй тип вполне можно использовать статические методы.
Третий тип зависит от кода. Если код нужен только в этом проекте, то лучше сделать сервис. Но если код может пригодиться в других проектах (особенно - не в symfony-проектах), то вполне можно сделать обычный класс и не делать сервис. Как пример, простой класс решения квадратного уравнения:

namespace MathFunctions;

class QuadraticEquation
{
    privatre $_x, $_y;
    private $_hasRoots;

    public function __construct($a, $b, $c)
    {
        $d = $b*$b - 4*$a*$c;
        if ($d >= 0) {
            $d2 = sqrt($d);
            $this->_x = (-$b + $d2) / (2*$a);
            $this->_y = (-$b - $d2) / (2*$a);
            $this->_hasRoots = true;
        } else {
            $this->_x = $this->_y = 0;
            $this->_hasRoots = false;
        }
    }

    public function hasRoots()
    {
        return $this->_hasRoots;
    }

    public function roots()
    {
        return $this->_hasRoots
            ? [$this->_x, $this->_y]
            : [];
    }
}

Зачем делать сервис, зачем размещать в проект? Вообще, как показал Андрей Инишев, лучше такие классы использовать через композер.

[Максим]

Алексей Павлов: как вы думаете сколько в самой Symfony кода, как в ваших примерах? А теперь найдите там статику.
Лучше уже тогда функцию в namespace определить.

Answer 3

[Максим]

Пишу полноценный ответ, как это должно быть в Symfony. Не пытайтесь переносить практики других фрейморков типо Yii и Laravel на Symfony, это разные продукты для разных целей.
В идеологии Symfony нет понятия хелпер как в Yii, ROR, Laravel. Вам необходимо объединить часто используемые функции в Service(называть это можно как угодно) по характеру функционала, поместить это в DI контейнер и инжектить в те классы в котором нужен этот сгруппированный функционал.
И задумайтесь, если у вас есть такие классы хелперы, которые используются направо и налево - значит вы промахнулись с архитектурным решением. Один класс одна обязанность. Понимание SOLID и практика поможет вам выйти на другой уровень объектного проектирования и разработки в целом.

Comments

[Владислав]

Большое спасибо за ответ, но вы немного не правы. Объясняю почему, да Symfony это не Laravel и т.д. но это так же просто каркас вашего приложения и вы можете расширять его возможности для реализации вашей задачи так, как хотите. То, что я предлагаю, абсолютно не нарушает принцип единой ответственности(SR), даже наоборот, я его соблюдаю. А вот предложение запихнуть всё в один сервис это как раз таки нарушение SR и даже нарушение ООП, потому что класс не должен быть просто помойкой с кучей методов. Реальный пример, у меня есть класс в котором мне нужно делать такое преобразование, 1000 => 1K, есть ещё другие классы где может применяться данный метод. Вы можете сказать: "Чувак, используй трейты, очевидно же". Да, трейты это круто, но таких методов помощников может быть много и оформлять каждый в трейт не целесообразно и усложнит логику. Вместо этого было бы намного удобнее просто создать обычные методы и всё.

[Максим]

Владислав: ключевое слово по функциональности, это не нарушает солид. А вот глобальная статика нарушает.

[Владислав]

Максим: Как именно нарушает?

[Максим]

Владислав: dependency inversion

[Владислав]

Максим: Обычный метод используемый в классе вообще не нарушает dependency inversion.

[Максим]

Владислав: Метод класса не нарушает, а статика это зависимость от другого класса.

[Максим]

Владислав: Кстати преобразование 1000 => 1K, это вообще View слой -> Twig расширение, зачем вам для этого нужна функция? Еще раз повторю, если у вас есть такие классы с набором общих функций, значит вы неправильно спроектировали приложение. Но все это касается только академически правильной разработки.
Трейты? Я ничего не говорил про трейты и использовал вообще их только пару раз в проектах в очевидных случаях, помоему потом еще и жалел об этом. Трейты также связывают ваш код и добавляют зависимости. Их использование спорный вопрос.

Answer 4

[Дмитрий Балобанов]

Service?

Comments

[Владислав]

Ну сервис тебе надо получать из DI container а я про глобальные функции типа как в Laravel