Как лучше передавать конфиг по “цепочке обязанностей”?

Question

[vitaly_74]

new PaymentOf(
    new ConcreatePaymentSystem(
        new CardForm(
            $_POST
        )
    )
);

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

$config = new Config(
[
    'secret' => [
        'secret_key' => '',
        'auth_key' => '',
    ],
    'db' => [
        'db_host' => '', //with db
        'db_name' => '', //with db
        'username' => '', //with db
        'password' => '', //with db
        'db_type' => 'mysql' //with db
    ],
    'urls'=>[
        'callback_url'=>'',//default
        'after_payment_url'=>'', //default
        'fail_url'=>'', //default
        'success_url'=>'', //default
    ]
]);

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

p.s. я знаю о существовании аналагов - но они меня не устраивают.

Comments

[Максим Федоров]

new PaymentOf(
    new ConcreatePaymentSystem(
        new CardForm(
            $_POST
        ),
        $config['secret']
    ),
    new Connection($config['db']) // этот объект лучше иметь один, а не плодить на каждый вызов
);

Вообще вам тут DI контейнера подошел бы

[vitaly_74]

Максим Федоров, нет, DI - это зло.

[Максим Федоров]

нет, DI - это зло.

вы хотели сказать DI-контейнер зло, а не DI?
Почему зло? Бугаенко перечитали? :)


так контейнер по итогу именно так и собирает объектики -- один в другой, просто эта сборка скрыта/упрощена... и по итогу в проектируете уже сами объекты, а их связями занимаетесь как конструктором...

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

[vitaly_74]

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

[vitaly_74]

Максим Федоров, "если руками, то перед вами будет много проблем и так или иначе придется прибегать к очень сложным паттернам, а тк кишки наружу — утонете в этих деталях, и по итогу шум деталей победит..." а можете пример привести? а я по возможности парирую?

[Максим Федоров]

vitaly_74,
ну начнем с первоисточника нашего разговора (ссылка с таймингом) https://youtu.be/ckjAWXJWZEY?t=2576

некоторые объекты (типа коннекшна) нужно передавать в несколько мест, либо программу совершенно иначе устраивать... вот вы упомянули контроллер -- это элемент MVC, против которого топит Бугаенко, то есть вам совершенно иначе как-то выстраивать программу свою

Вот я уже приводил проблему, но в реальности ваш код будет выглядеть в разы больше и шумнее:
Зачем нужен контейнер если php умирает?

....
Пример:
Есть отличный паттерн Observer/Mediator, он отлично показывает нам Ioc (Inversion of Control)...
Вы его прямо на ходу каждый раз будете городить? Нет скорее всего выстроите замену, в виду огромной цепочки декораторов, в которых основная ответственность просто затеряется...
То есть было: есть зависимость EventDispatсher и он выкинул событие, просто нужно его прослушать где-то выше по слою и вызвать другие объекты, которым это осбытие интересно
Станет: вы обернете декораторами-обработчиками целый слой вызовов, чтобы он отработали внутри/снаружи (не готов даже понять сейчас как это будет работать)

[Максим Федоров]

Тестировать такие простенькие декораторы и правда просто, но конструктор из них -- не думаю ,что это тривиальная задача

[vitaly_74]

Максим Федоров, да вот про mvc, сам пользуюсь, это удобно. но вот есть фреймворк - хорошо. все что идет до контроллеров и экшенов - это фреймворк, остальное можно как сказал Бугаенко.
один экшен уникальное событие, которые можно и составить + алгоритм экшена понятен.
согласен что каждый раз большую конструкцию не нужно разворачивать, но уникальный экшен такого требует. экшенов много, событий много, объектов еще больше, и нужно это все быстренько понять.

[vitaly_74]

Максим Федоров, "вы обернете декораторами-обработчиками целый слой вызовов, чтобы он отработали внутри/снаружи (не готов даже понять сейчас как это будет работать)"
таких проблем еще не встречал) но встречу, обращусь к вам за советом)

[Mikhail Osher]

vitaly_74, если Вы считаете правильным говорить "di зло" и "хочу сам создавать объекты", то у меня для Вас плохие новости. Таким образом, Вы пишете сильно связанный, нетестируемый и нерасширяемый код.

[vitaly_74]

Mikhail Osher, увы нет.