DI с new FooClient(new HttpClient(new RetryStrategy())) — если честно, я не оч понял шутку

то есть так делать не надо?

Я даже не знаю, что тут хуже — жёсткий штырь иерархии зависимостей или то, что тут нет DI

Я даже не знаю, что тут хуже — жёсткий штырь иерархии зависимостей или то, что тут нет DI

ну dic подразумевается там

Я даже не знаю, что тут хуже — жёсткий штырь иерархии зависимостей или то, что тут нет DI

DI тут есть. а вот решать, когда надо повторить запрос, должен клиент конкретного api, а не условный httpClient. тут я плохое посоветовал

DI тут есть. а вот решать, когда надо повторить запрос, должен клиент конкретного api, а не условный httpClient. тут я плохое посоветовал

Создавать равноправные сущности через вложенные new — это инъекция не зависимостей, а технического долга

блин, ну не надо так буквально воспринимать

нет там никаких new

ну все зависит от желания... если надо быстро кое-как зарефакторить, разбиь логику и запросы - то можно и декораторами, и мидлварями... а если стоит задача "создаь идеальное решение", то тут канеш нужно свою суперлибу пилить, уровня guzzle

Давно существуют обобщённые способы

ану? жду ссылку

Начиная прям со стримов с фьючерсами

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

на пхп

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

чтобы реализовать логику _ на _ тоже надо уметь

в чем разница между абстрактным классом и интерфейсом? класс наследуется только 1, в то время как интерфейсов множество можно реализовать

?

или эта разница строится в понимании при проектировании где испольовать класс, а где интерфейс

мож статья есть какая) за ссылку буду благодарен

надо еще конкретизировать язык

в Java интерфейсы могут иметь реализацию, но не могут иметь стэйт

в чем разница между абстрактным классом и интерфейсом? класс наследуется только 1, в то время как интерфейсов множество можно реализовать

в С++ есть только классы и все хорошо)

надо еще конкретизировать язык

С#

в С++ есть только классы и все хорошо)

Это да)

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

правда мы тут это уже обсуждали и мое мнение тут не в почете :)

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

нужна просто удобная композиция и все

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

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

в чем разница между абстрактным классом и интерфейсом? класс наследуется только 1, в то время как интерфейсов множество можно реализовать

Разница не техническая, а смысловая. Интерфейс описывает то, что нам нужно от объекта. Как объект должен выглядеть. Как себя вести снаружи. А класс - это уже ближе к самому коду объекта (реализации) внутри. Но по совместительству класс тоже имеет свой интерфейс. А на практике получается https://yiiframework.ru/forum/viewtopic.php?f=34&t=44999&p=225042#p225000

Разница не техническая, а смысловая. Интерфейс описывает то, что нам нужно от объекта. Как объект должен выглядеть. Как себя вести снаружи. А класс - это уже ближе к самому коду объекта (реализации) внутри. Но по совместительству класс тоже имеет свой интерфейс. А на практике получается https://yiiframework.ru/forum/viewtopic.php?f=34&t=44999&p=225042#p225000

спасибо!

я тут опять со своим дурацким клиентом к сторонним апи... думаю как повышать качество кода. конечно хорошо бы все запросы к апи делать асинхронно через очередь. но есть нюанс, некоторые запросы подразумевают цепочку вызовов. например, сначала нужно получить токен, причёт токен может выдаться не с первого раза и нужно сделать до 5 попыток с паузой 15 сек. после успешного получения токера нужно дёрнуть другой эндпоинт и получить результат. естественно все эти паузы лучше всего переложить на брокера очередей. а вот как оформить цепочки вызовов - вопрос... есть какие-то реализации подобного?

есть. у микрософта даже целый фреймворк есть под это дело. wwf.

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

и состояния. типа количества прошлых попыток

я тут опять со своим дурацким клиентом к сторонним апи... думаю как повышать качество кода. конечно хорошо бы все запросы к апи делать асинхронно через очередь. но есть нюанс, некоторые запросы подразумевают цепочку вызовов. например, сначала нужно получить токен, причёт токен может выдаться не с первого раза и нужно сделать до 5 попыток с паузой 15 сек. после успешного получения токера нужно дёрнуть другой эндпоинт и получить результат. естественно все эти паузы лучше всего переложить на брокера очередей. а вот как оформить цепочки вызовов - вопрос... есть какие-то реализации подобного?

Saga

Слово сага очень плохое для загугла

Слово сага очень плохое для загугла

http://microservices.io/patterns/data/saga.html

Слоожна((

проще, чем кажется)

Слоожна((

если просто - ивенты и некто кто слушает ивенты и паблишит команды.

ивент - факт того что что-то произошло, команда - запрос на действие

а сага только координирует и отдаёт команды

Да, Сага о процессе, она лишь скрепляет части вместе

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

типа сначала что-то в статусе pending, потом либо done либо failed

Ну, не обязательно. Сага может и не делать ничего изменяющего до финального шага. А копить всё в себе. Зависит от требований и реализации.

не ну она копит че было по идее

ну то есть необходимые данные для последующих команд

Я к тому, что она может, аки транзакция менять данные в процессе жизни (и откатываться в случае факапа), а может ничего не менять вплоть до последнего шага, на котором уже выполнить пачку агрегированных действий. Или не выполнит. Типа, как flush

Данные не внутри саги, а дергать какую-то бизнесс логику.

Я к тому, что она может, аки транзакция менять данные в процессе жизни (и откатываться в случае факапа), а может ничего не менять вплоть до последнего шага, на котором уже выполнить пачку агрегированных действий. Или не выполнит. Типа, как flush

типа uow, только для вызовов методов (к примеру)?

типа uow, только для вызовов методов (к примеру)?

Как-то так, да

Ну т.е. философии саг сие никак не противорочит. У меня, например, оба варианта вполне себе сосуществуют

Ну т.е. философии саг сие никак не противорочит. У меня, например, оба варианта вполне себе сосуществуют

ну в общем - то да, они могут иметь свой стейт, строящийся на базе полученных ивентов

ну в общем - то да, они могут иметь свой стейт, строящийся на базе полученных ивентов

Именно.

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

Над самому будет посмотреть что за зверь. Меня текущий вариант устраивает чуть менее, чем полностью, но мало ли

вернусь домой и оформлю этот конверсейшн в фак-страничку нашу, имхо будет полезно

Над самому будет посмотреть что за зверь. Меня текущий вариант устраивает чуть менее, чем полностью, но мало ли

ну то ведь под фронт заточено, мне просто интересно с теоретической точки зрения

А есть разница между фронтом и бэком?)

ну то ведь под фронт заточено, мне просто интересно с теоретической точки зрения

Я чет на вскидку не придумаю отличий)

А есть разница между фронтом и бэком?)

с точки зрения теории нет, с точки зрения практики - да) я больше о том, что твоё сообщение звучит как "может заюзаю" но если ты об идеях - тогда да, может пригодиться

а про разницу... она в первую очередь в восприятии кода и структуры приложения

Не) меня мой говно паб/саб устраивает) Я больше на идеи глянуть. Мб есть какая-то вундерфича

а про разницу... она в первую очередь в восприятии кода и структуры приложения

У нас саг до жопы просто... часть на джаве выполняется, часть в мерзком пхп, часть в голанге... Трудно народу объяснять с помощью каких высших сил и чьей матери это всё рпботает. Но потом втягиваются и все ок)

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

посмотрел, почитал... странная какая-то штука эти ваши фронтэнды

https://blog.jetbrains.com/pycharm/2018/04/python-37-introducing-data-class/

Слушайте, а что почитать можно по ООП? О том как правильно нужно. Прочита статью старую, про то что геттеры/сеттеры есть плохо, что мол это все не правильно и не ОО. Статья конечно хуйня постная, но задумался, есть ли что-то далше OOP in PHP от занстры

У меня есть вот такой вопрос

допустим есть 2 программиста да.Оба закончили бакалавр и вот потом один из них работал в компаний 1 лет а другой делал не коммерческие проекти дома но написал больше код чем тот который в компании работал.

У кого будет больше шанса получить новая работа из этих 2 кандидатах ?

или скажем кто будет цениться больше в рынке

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

хмм

скажишь типа нет важная разница

спасибо за ответ

жизнь несправедлива

Слушайте, а что почитать можно по ООП? О том как правильно нужно. Прочита статью старую, про то что геттеры/сеттеры есть плохо, что мол это все не правильно и не ОО. Статья конечно хуйня постная, но задумался, есть ли что-то далше OOP in PHP от занстры

https://www.youtube.com/playlist?list=PLmqFxxywkatStbd9hdzVOS1hZa9dc56k4

10 часов лекций, почти всё про ООП)

про мою головоломку с апи, перезапросами и т.п. пока сделал так:

в джобе описываются шаги по порядку, если шаг выбрасывает эксепшен JobException($step, 5, 3); то он повторяется до 3х раз с паузой 5 сек. в итоге логика перезапросов не копируется по всему коду и ей удобно управлять. к тому же можно легко начинать выполнение с любого шага =) критикуйте, кидайте какулями

Кинул какулю за шиворот. Просто так.

ммм, кайф

ммм, кайф

По поводу кода какушатами забрасывать не вижу смысла.

если у тебя есть таблиц 100+ колонок. значит чтото пошло не так))

нужна колоночная бд

если много null особенно

Никто не может скинуть ссылки или книгу назвать. Где можно прочитать про различные архитектуры. Я читал Martin Fowler Patterns of enterprise application architecture. Но не нашел там то что хотел.

А то я понял пока, только то, что если приложение сильно расширяется, юзай микросервисы/

soa еще