Битрикс: от модулей к сервисам 225.12.2024 10:00

И применяем к нашему классу:

get(self::class);

   }

   public function __construct(

       private OrderRepository $repository,

       private ExchangeService $exchangeService

   )

   {

   }

   public function repository(): OrderRepository

   {

       return $this->repository;

   }

   public function exchange(): ExchangeService

   {

       return $this->exchangeService;

   }

}

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

public function __construct(

       private OrderRepository $repository,

       private ExchangeService $exchangeService

   )

Так, мы можем получить доступ к методу по пути OrderService::create()->repository()->getDealRepositoryByDealId($id);

Но если заметили, в методе create () используется какой-то Container ()? Так вот, если мы вернем DI-инъекцию классов, то они будут требовать объявления передаваемых объектов, и нам придется прописывать инициализацию для всей структуры в каждой зависимости, на каждом уровне, что очень кропотливо.

return new self(new OrderRepository(), new ExchangeService());

Если брать symfony и laravel, то там это решается при помощи хелперов app (). Вот выдержка из документаций:

If you are using it as in your example — you’ll get no profit. But Laravel container gives much more power in this resolving that you cannot achieve with simple instantiating objects.

1. Binding Interface — you can bind specific interface and it’s implementation into container and resolve it as interface. This is useful for test-friendly code and flexibility — cause you can easily change implementation in one place without changing interface. (For example use some Countable interface everywhere as a target to resolve from container but receive it’s implementation instead.)

2. Dependency Injection — if you will bind class/interface and ask it as a dependecy in some method/constructor — Laravel will automatically insert it from container for you.

3. Conditional Binding — you can bind interface but depending on the situation resolve different implementations.

4. Singleton — you can bind some shared instance of an object.

5. Resolving Event — each time container resolves smth — it raises an event you can subscribe in other places of your project.

And many other practises… You can read more detailed here http://laravel.com/docs/5.1/container

В нашем случае мы вручную создадим динамический контейнер, который нам вернет инстанс со всеми иерархическими объявлениями:

objects[$id]) || class_exists($id);

   }

   /**

    * Метод возвращает инстанс класса по его ключу.

    *

    * @param string $id

    * @return mixed

    * @throws ArgumentException

    */

   public function get(string $id): mixed

   {

       try {

           return

               isset($this->objects[$id])

                   ? $this->objects[$id]()         // "Старый подход"

                   : $this->prepareObject($id); // "Новый" подход

       } catch (ContainerExceptionInterface|NotFoundExceptionInterface|Exception $exception) {

           throw new ArgumentException($exception->getMessage());

       }

   }

   /**

    * @throws Exception

    */

   private function prepareObject(string $class): object

   {

       try {

           $classReflector = new ReflectionClass($class);

           // Получаем рефлектор конструктора класса, проверяем - есть ли конструктор

           // Если конструктора нет - сразу возвращаем экземпляр класса

           $constructReflector = $classReflector->getConstructor();

           if (empty($constructReflector)) {

               return new $class;

           }

           // Получаем рефлекторы аргументов конструктора

           // Если аргументов нет - сразу возвращаем экземпляр класса

           $constructArguments = $constructReflector->getParameters();

           if (empty($constructArguments)) {

               return new $class;

           }

           // Перебираем все аргументы конструктора, собираем их значения

           $args = [];

           foreach ($constructArguments as $argument) {

               // Получаем тип аргумента

               $argumentType = $argument->getType()->getName();

               // Получаем сам аргумент по его типу из контейнера

               $args[$argument->getName()] = $this->get($argumentType);

           }

           // И возвращаем экземпляр класса со всеми зависимостями

           return new $class(...$args);

       } catch (ReflectionException|ContainerExceptionInterface|NotFoundExceptionInterface $e) {

           throw new Exception($e->getMessage());

       }

   }

}

Таким образом, все внедренные зависимости в сервис всегда будут одним и тем же объектом, и мы сможем изменять значения в дочерних классах, при этом в самих классах, используя зависимости, к примеру:

CurlService::create()->client()->setUrl($url);

CurlService::create()->actions()->send($message);

Так как в CurlActions такой же инстанс подключается через иерархическую зависимость:

readonly class CurlActions implements ActionsInterface

{

   /**

    * @throws ArgumentException

    * @throws SystemException

    */

   public function __construct(

       private CurlClient $client

   )

   {

       $this->client->init();

   }

2. Инфраструктурные сервисы

Раз мы заговорили о CURL, он является типичным представителем инфраструктуры, но легко заменяется тем же Guzzle, и большинство сервисов инфраструктуры легко взаимозаменяемы, как, например, разные провайдеры СМС.

Тут нам понадобится фабрика, построенная на интерфейсах, а не конкретной реализации. К примеру, у curl и guzzle должен быть метод init (), метод setBody () и метод send (). А вот их конкретная реализация нас мало интересует.

Подготавливаем родительский интерфейс для сервиса:

value): ServiceInterface

   {

       return match ($typeId) {

           ServicesEnums::CURL->value => (new Container())->get(CurlService::class),

           ServicesEnums::GUZZLE->value => (new Container())->get(GuzzleService::class),

           default => throw new Exception('Unexpected match value'),

       };

   }

   /**

    * Логирование обмена данными.

    *

    * @param HttpRequestInterface $context

    * @param TypeEnums $type Источник логов.

    * @return void

    */

   public static function log(HttpRequestInterface $context, TypeEnums $type = TypeEnums::ORDERS): void

   {

       $method = debug_backtrace()[1]['function'];

       $message = "Http: {$context->method}::{$method} [{$context->id_entity}]";

       LoggerFacade::app('Http' . DIRECTORY_SEPARATOR . $context->service . DIRECTORY_SEPARATOR . $type->name . DIRECTORY_SEPARATOR )->info($message, (array)$context);

       LoggerFacade::elk()->info($message, (array)$context);

   }

}

client;

   }

   public function repository(): RepositoryInterface

   {

       // TODO: Implement repository() method.

   }

   public function actions(): CurlActions

   {

       return $this->actions;

   }

}