MoscowPython Meetup 80: Зачем нужен и как использовать Dependency Injection в питонячих сервисах
На очередной встрече MoscowPython Meetup 80 мы обсудили тему Dependency Injection в питонячих сервисах. Зачем он нужен и как его правильно использовать?
Dependency Injection – это паттерн проектирования, который позволяет управлять зависимостями между компонентами программы. Он особенно полезен в больших проектах, где есть много классов и объектов, которые используются друг другом. С помощью Dependency Injection мы можем легко изменять зависимости между компонентами, что делает код более гибким и поддерживаемым.
В питонячих сервисах Dependency Injection может быть использован для инъекции зависимостей в конструктор класса или методы. Это делает код более чистым и позволяет легко тестировать его.
Пример использования Dependency Injection в питонячих сервисах:
class Service:
def __init__(self, dependency):
self.dependency = dependency
def do_something(self):
result = self.dependency.calculate()
return result
Здесь мы создаем класс Service, который принимает зависимость dependency в конструкторе. Это позволяет нам легко заменять зависимость при необходимости, например, при тестировании.
На MoscowPython Meetup 80 мы поговорили о том, как правильно применять Dependency Injection в питонячих сервисах и делились своими опытом и лучшими практиками.
Будем надеяться, что наш разговор поможет вам лучше понять и использовать Dependency Injection в ваших проектах!
Какое же убожество этот ваш DI
Шикарный доклад, шикарная тема, надо поддерживать коллег, а не искать недостатки. Автор молодец.
На 7:20 DI у автора реализован через service locator со всеми его недостатками.
DI в питоне как корове седло – некто Бобук
Лектору нужно над своим базаром задуматься
Тема не раскрыта
1:39 Мех. Хорошо, то в джаве невозможно писать лапшеобразный код, ведь там есть TransactionAwarePersistenceManagerFactoryProxyPersistenceManagerFactoryInvocationHandler
7:00 Ну т.е. мы инициализируем классы как глобальные переменные. Т.е. они будут инициализированы в момент первого импорта. Такое видел только у новичков, которых сразу бьют по рукам. Для этого существует объект приложения, в котором мы храним соединения с бд, почтовые клиенты и.т.д. и достаём их из объекта запроса. Я понимаю, что после 10-лет джавы сложно такое предствить, но в питоне есть просто данные и просто функции, которые могут эти данные принимать. Создаваться это всё должно в момент инициализации приложения, в условном def run, и передаваться дальше, а не шариться по всему приложению. Что будем делать, если нам нужно получить доступ к объекту почтовика из разных потоков? Удобно будет с этим работать? Зачем тащить из других языков чуждые этому языку концепции и пытаться их натянуть?
Че то на 6 минуте от датакласса офигел. Ну почему нельзя было показать просто с методом инит? Ведь датакласс существует не только для того, чтобы написать за вас метод инит, он в целом определяет концепцию класса и она здесь явно не подходит, потому что Биллинг – ну никак не датакласс, особенно учитывая что в нём прописана бизнес-логика.
Я конечно понимаю, что многие воспримут мой коммент как до*б, но на самом деле такие концептуальные вещи это ж капец как важно, и уж точно на конфах не хочется видеть такие уродливые конструкции, когда датакласс лепят куда ни попадя, при том что это еще и чуть усложняет объяснение смысла материала (с методом инит было бы тупо нагляднее).