Как отделить абстракцию от реализации?

Question

[Игорь]

Поделитесь опытом отделения абстракции от реализации в symfony.

Идея следующая:
Мы хотим реализовать несколько реализаций для одного и того же действия.

Например:

/**
     * @Route(
     *     path="/bridge/call/{variant}",
     *     methods={"GET"}
     * )
     * @param string              $variant
     * @param AbstractionExecutor $abstractionExecutor
     *
     * @return Response
     */
    public function call(
        string              $variant,
        AbstractionExecutor $abstractionExecutor
    ): Response
    {
        if ($variant === 'b') {
            $abstractionExecutor->setImplementation(new ConcreteImplementationB());
        } else {
            $abstractionExecutor->setImplementation(new ConcreteImplementationA());
        }

        return new Response($abstractionExecutor->exec());
    }

Используется паттерн "Мост"
Взял пример здесь

Что хотелось бы узнать.
-----------------------------------------------------------------------------
- Структура хранения классов.
- Инициализация в зависимости от установленных правил.

Какие есть нюансы?
Кто решал похожую задачу?

Comments

[BoShurik]

Нужно больше контекста. В AbstractionExecutor у вас есть какая-то логика? Или вся логика в имплементациях, а Executor просто их дергает?

[Игорь]

BoShurik, Вся логика в имплементациях.

Answer 1

[BoShurik]

interface ExecutorInterface
{
    public function exec(): string;
}

class ConcreteImplementationA implements ExecutorInterface
{
    public function exec(): string
    {
        return 'A';
    }
}

class ConcreteImplementationB implements ExecutorInterface
{
    public function exec(): string
    {
        return 'B';
    }
}

class VariantExecutor
{
    public function __construct(private ServiceLocator $locator)
    {
    }

    public function exec(string $variant): string
    {
        return $this->locator->get($variant)->exec();
    }
}

class Controller
{
    public function call(VariantExecutor $executor, string $variant): Response
    {
        return new Response($executor->exec($variant));
    }
}

#services.yaml
app.executor.locator:
    class: Symfony\Component\DependencyInjection\ServiceLocator
    arguments:
        -
            a: App\ConcreteImplementationA
            b: App\ConcreteImplementationB
    tags:
        - { name: container.service_locator }

Comments

[Игорь]

Сейчас посовещались с коллегами.
Можно попробовать через "аргумент резольвер" реализовать данную задумку.

[BoShurik]

Игорь, Можно, но ИМХО того не стоит. Если я правильно вас понял, будет что-то вроде:

public function call(ExecutorInterface $executor): Response
{
    return new Response($executor->exec());
}

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

[Игорь]

BoShurik,

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

Да.

Я понимаю, в Symfony хватает магии.

[Игорь]

BoShurik, Не будет ли представленное вами решение громоздким?

[BoShurik]

Игорь, В чем громоздкость? Классов чуть больше, но они небольшие и лаконичные, изменения в них почти наверняка вводится не будут. Добавление новых имплементаций будет заключаться в добавлении конфигурации локатора. В вашем случае придется добавлять условие и инстанцировать нужный класс. При этом заметьте, что в вашем случае не решена проблема наличия у имплементаций зависимостей. В этом случае код не будет таким лаконичным

[Игорь]

Вот что у меня получилось.

/**
     * Удаление проекта.
     *
     * @Route(
     *     path="/{project_id}",
     *     methods={"DELETE"}
     *     )
     * @param int             $project_id
     * @param VariantExecutor $executor
     *
     * @return Response
     */
    public function delete(
        int             $project_id,
        VariantExecutor $executor
    ): Response
    {
        return $executor->exec("project_delete");
    }

/**
 * Удаляет проект.
 */
class Delete extends AbstractDomain implements ExecutorInterface
{
    /**
     * @return JsonResponse
     * @throws NotFoundException
     */
    public function exec(): JsonResponse
    {
        $projectRepository =  $this->getEntityManager()->getRepository(Project::class);

        $project = $projectRepository->find($this->getRequest()->get("project_id"));

        if (!$project instanceof Project) {
            throw new NotFoundException("Project not found");
        }

        $project->setDeleted(true);

        $this->getEntityManager()->flush();

        return $this->json([
            "message" => "ok"
        ]);
    }
}

[BoShurik]

Игорь, ощущение, что тут абстракция ради абстракции. Почему просто не передать Delete минуя VariantExecutor?

public function delete(
    int             $project_id,
    Delete $executor
): Response
{
    return $executor->exec();
}

[Игорь]

BoShurik, Нужен посредник, в котором реализация будет подменяться в зависимости от условий.

Например, будут базовые реализации и расширенные.
Расширенные будут применяться в зависимости от условий.
+ Хотелось бы перехватывать каждый вызов.

[Игорь]

Возможно в будущем запилить версионирование реализаций.

[BoShurik]

Игорь, а можете привести пример? Как может поменяться реализация удаления?

[Игорь]

Например, в так называемом сервис менеджере можно реализовать некоторую логику.

/**
     * @param string $id
     *
     * @return JsonResponse
     * @throws BadRequestException
     */
    public function exec(string $id): JsonResponse
    {
        // Получить информацию о подписке.
        // $subscription = $this->getUser()->getSubscription();

        // Проверить наличие реализации.
        if (!$this->locator->has($id)) {
            return new JsonResponse([
                "error_code" => null,
                "error_message" => "Method not found",
                "errors" => [],
            ]);
        }

        $service = $this->locator->get($id);

        // Валидатор
        if (method_exists($service, "validate")) {
            $violations = $service->validate();
            if (count($violations) > 0) {
                $errors = [];
                foreach ($violations as $violation) {
                    $errors[] = [
                        "property_name" => $violation->getPropertyPath(),
                        "value" => $violation->getInvalidValue(),
                        "message" => $violation->getMessage(),
                        "code" => $violation->getCode()
                    ];
                }
                throw new BadRequestException("Bad Request","bad_request", $errors);
            }
        }

        return $service->exec();
    }

[Игорь]

BoShurik,

Игорь, а можете привести пример? Как может поменяться реализация удаления?

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

Ну например.
Метод получения списка контактов, будет трёх вариантов, при этом хотим сохранить универсальность RestAPI и чистоту + тонкий контроллер.

[Игорь]

Я так думаю, что будет какая-то базовая реализация, а если клиент приобрёл подписку, будет использоваться уже другая реализация.

Не хочется писать бороду в контроллерах.