+ Ещё стоит почитать про то как работают те или иные вещи в твоём основном языке. Те же list comprehension во что превращаются в рантайме или как работают генераторы, на сколько и то и то тяжёлое и где лучше использовать их, а где циклы.
+ Математику ещё надо прокачать, тк многие вещи не очень очевидны без неё и многие олимпиадные задачки решаются чисто через какой-нибудь математический трюк.
По практике - есть литкод, там также по каждой отдельной теме есть задачки (только читай условия внимательно, тк часто на хард задачках там есть требования типа "уложиться в такой-то big-O" или "не использовать дополнительную память".
Звучит ещё хуже, если честно)
Чем не устроил нормальный dependency injection?
Какую тогда вообще пользу даёт фасад? Почему мы потребителю напрямую к этому контейнеру не обратиться?
Нет, тк в текущей реализации сразу несколько проблем
1. Циклическая зависимость (которая потенциально может к рекурсии привести и когда-нибудь приведёт)
2. Гвоздями прибиваешь свой домен к инфраструктуре
Чем не устроила "тупая" архитектура?
Контроллер (обработчик http-запросов) -> сервис (доменный, который отвечает за бизнес-правила) -> базовая инфраструктура (запросы к сторонним сервисам, очереди, базы данных)
И связать их все при помощи dependency injection.