Как реализовать функционал с учётом принципа инверсии зависимостей?

Question

[00O]

Есть проект на Laravel который обращается к нескольким внутренним REST API.
Сейчас это реализовано так:
Есть абстрактный класс, в котором есть метод

protected function send(string $verb, string $endpoint, array $params = []): Response
{
    return $this->http->$verb($endpoint, $params);
}

и 2 класса, которые его расширяют кучей разных методов (каждый своими), которые вызывают внутри себя $this->send(...) с нужными параметрами. Количество этих методов постоянно увеличивается т.к. API дополняются. В контроллерах тот или иной класс API мы внедряем не через абстракцию, а указав конкретную реализацию. Да и не может у них быть общего интерфейса по определению, это ведь разные API. Получается, абстрактный класс используется только для шеринга метода send(), а методы классов для вызова его с нужными параметрами.

Прочитал https://habr.com/ru/post/313796/ , но не могу понять как реализовать существующий функционал с учётом принципов из статьи. Если не сложно, объясните, пожалуйста.

Я могу представить если нам нужно заменить, например, хранилище. Меняем MySql базу на файл, все методы остаются теми же (т.е. интерфейс единый), но меняются реализация. А тут? Может я хочу применить принцип не для той задачи?

UPD: я тут подумал. Замена реализации мне не нужна, получается. Я точно знаю в каких местах в коде обратиться к одному API а где к другому. И там нужна именно необходимая в том месте реализация, без возможности её подменять. Но этот факт не делает код лучше.

Answer 1

[profesor08]

Разные API для разных задач, соответственно у них будут разные классы и методы. Общее у них будет только механизм отправки запросов, что можно добавить наследованием, или расширить их через трейты.

Comments

[00O]

Т.е. существующее решение в рамках конкретной задачи не самое плохое?

[monday_suicide]

для хранилища можно написать фабрику, которая будет поддерживать разные типы хранилища.

[profesor08]

00O, выходит так

[Vitsliputsli]

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

[profesor08]

Vitsliputsli, ну оба класса работают с апи и шлют http запросы, смысла писать для каждого реализацию для отправки http запросов нет.

Уж лучше задублировать метод, чем разбираться что "намешано" в коде.

Это если нужна разная реализация, а если одинаковая, то стоит задуматься стоит ли оно того. Потому что в случае бага, или необходимости доработок, придется править их все.

[Vitsliputsli]

profesor08, именно, поэтому в таком варианте пишется класс отправки http-запросов, универсальный, а не зависящий от реализации какого-то конкретного API.

Answer 2

[Vitsliputsli]

Какие еще классы разных API? REST API - это механизм взаимодействия, это внутренняя реализация, которая почему-то вытащена на верхний уровень, до уровня контроллеров. У вас должны быть бизнесовые сущности, и к объектам этих сущностей применяйте Принципы. А уже на более низком уровне для передачи данных бизнесовых сущностей используйте объект класса RestAPI, в котором, разумеется, не должно быть никаких завязок на специфику выше стоящих бизнесовых сущностей.
Ваш метод send выглядит странно, зачем он вообще нужен? Динамические методы это очень неудобно, IDE по ним вам ничего не подскажет и придется разгадывать этот ребус самому, а ничего более этот метод не делает.