и часть из них необязательная была бы

тогда такую штуку можно применить, но твой случай значительно проще

и некоторые и все они не необязательные

проблема в том что будут ещё методы в классе, я больше думал о сопровожденнии кода

у нас куча разных сервисов

я сейчас стараюсь команде объяснить и народ стал понимать плюсы

мы каждому сервису что интегрируем создаем свой класс с методами что описаны в доке

и результаты в качестве vo обычных делаем (на основе доки)

получается например сервис1 он рест ему передается клиент газл и параметры для авторизации

сервис2 он на soap например, ему передается стандартный soap client и параметры для авторизации

эти сервисы это как бы разные классы апи

и таких реализаций у нас довольно много (много интеграций)

тогда нааерно удобней реализовать интерфейс который реализуют оба класса с api

например у нас несколько платежных систем подключено

не совсем

например у нас есть условно 3 платежные системы для оплаты 1. payture 2. sber 3. без нал

у каждой из этих систем абсолютно разные апи

и таких реализаций у нас довольно много (много интеграций)

Вы передаёте как газл?

Не DI?

di

Т.е. в конструкторе сервиса газл?

Api разные, но смысл остатется тот же SendMoney и тому подобное

я конечно могу полную тупость говорить, я мало в этом понимаю, но мне кажется тут надо делать общий класс который будет реализовывать общие методы, тогда можно использовать полиморфизм

у нас есть следующее PaytureGateway ($guzzle, $username, $password)- это реализация апи на основе доки от того с кем интегрируемся у всех свои методы и тд SberGateway ($soap, $username, $password) - тоже самое есть еще PaymentInterface тут общие методы типо block, refund и тд есть еще реализации платежных систем которые адаптируют gateway конкретный в PaymentInterface например PayturePayment($paytureGateway), SberPayment($sberGateway); и весь остальной код зависит от PaymentInterface

вот полиморфизм тут на интерфейсах

в моем примере весь остальной код зависит от PaymentGateway

который в зависимости от способа оплаты выбирается

если делаешь общий базовый класс, то придется юзать наследование, а это ограничение ты зависешь от одного базового класса, остальное будешь в трейты складывать

"block" не надо людей неймингу учить только...) да и в целом примеры говно)

абстрактный класс

А как собирается объект? new Payture($guzzle, $myusername, $mypass) ?

А как собирается объект? new Payture($guzzle, $myusername, $mypass) ?

обычный di

лара 4.2 например, у нас

автоматом цепляет часть параметров конфигах

Ну в ларе ж нельзя часть задать, а часть через di?

так газл собирается автоматом а параметры на этапе загрузки в di проставляются

и потом по имени переменной подгружаем

Через сервис провайдер?

там не просто $username а что то типо $sberUsername и этот параметр по имени в конфиге лежит

Через сервис провайдер?

нет

Пятую Лару использовал и не видел такого там

у меня своя обертка для di

я туда лару впихнул

сейчас найду

вот в мое либе пример но немного старая версия либы https://github.com/smpl/mydi/blob/master/test/Documentation/reflectionService.php

для di

например параметр $a будет искаться в di по \stdClass $b - будет юзать анотацию inject и реально туда проставиться A1 $c1 - будет использоваться по имени

Понял

только теперь вместо c1 и B1 параметры в конфиге лежат и на этапе загрузки он читается и проставляется

В ларе разве что binding primitives я помню

ну да типо этого я свою либу юзаю но и в ларе если покопаться можно сделать

если что на крайняк

$this->app->when('App\Http\Controllers\UserController') ->needs('$variableName') ->give($value);

Как то так там

App::singleton(PaytureGateway::class, function($app) { return new PaytureGateway($app->get(Client::class), $app->get('sberUsername'), $app->get('sberPassword'));

в 4.2 можно

но мы в конструкторе просто имя входного параметра задаем что то типо $sberUsername и все автоматом резолвится

ну это чисто наша кухня)

ERROR: S client not available

Понял

Забавно, читаю доку Лары. Там psr-11

у меня в моей доке тоже psr-11 ?

в моей либе

вообще норм di php-di.org

благодарю за ссылку, как раз сейчас с сервисами в symfony начал разбиратся

На ларовский ни разу не жаловался тоже. В отличии от yii2

в ларе норм

даже в 4.2

А чего вы не обнлвитесь на 5?

Тяжко?

вагон легаси

Можно подумать главная проблема легаси - большое кол-ва строк кода)

В этих ваших модных ооп строк в разы больше by design. И чё?)

В этих ваших модных ооп строк в разы больше by design. И чё?)

ты будто бы легаси на ООПе не писал)

ты будто бы легаси на ООПе не писал)

Я в жизни делал много говна...)

в качестве примера - видел проектик на гитхабе в 1.6 миллиона строк которые могут быть зарефакторены примерно в 200К строк (без учета вендоров конечно). Много дублирования, кучи каких-то невнятных велосипедов которые можно заменить на готовые компоненты...

Вызываем хелбоя для рефакторинга ;)

о да... этот может)

Будет 10кк)

"мы увеличим количество строк в вашем легаси на порядок"

"мы увеличим количество строк в вашем легаси на порядок"

Смотри что б только на 1) база-то не маленькая ;)

так к чему вопрос?

пффф... вообще не предел.

смотреть надо не на количество кода а на связанность. Есть тупой говнокод и есть "хитрый", и вот последний сложнее.

Кол-во кода - херовая метрика. Есть вполне понятные метрики, которые ещё укажут на его качество)

"так" - мы не знаем как

потому ничего не можем прокоментировать