Коллеги, правильно ли реализовал код по принципу инверсии зависимости? https://github.com/Khanze99/language_python_lessons/blob/main/solid/DIP/1.py Задача была

в том, чтобы разделить зависимость, не ссылаться на конкретные классы, не наследовать их.

А то как-то сомнительно немного.

Ну, в задаче, Application использует конкретную реализацию ConcreteImpl, через интерфейс Service. 1. IServiceFactory так и есть в коде, по неймингу 2. тут поправил, в общем и целом make_svc - создает экземпляр ConcreteImpl и возвращает его как экземпляр интерфейса Service Немного поменял: https://github.com/Khanze99/language_python_lessons/blob/main/solid/DIP/1.py

Добавь аннотации типа результата для make_svc

ща

добавил

не везде добавил

в абстрактном методе нужно что-то аннотировать? только эти методы по сути есть

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

А если в разных реализация этого метода в разных классах будут разное возвращения экземпляров, но родитель у них один? Тогда в абстрактный добавить родителя этих конкретных реализаций?

а как ты собираешься это юзать?

давай ты эти все фабрки выикнешь и начнешь с простого вопроса: что нужно Application чтобы он работал?

Ну, в принципе асбтрактно, из книги "Чистая архитектура" тема Принцип инверсии зависимости. Но давай попробуем. Application использует конкретную реализацию ConcreteImpl через интерфейс IService. Вот в принципе первое условие.

попробуем с другой стороны - зачем тебе знать что объект имеет тип ConrecteImpl?

Наверное потому что: 1. имеет конкретную какую-то реализацию 2. не зависеть конкретно от IService, по принципу DIP

зачем тебе знать какая именно реализация сделана? реализация чего вообще? как не зависить от IService, если ты сам выбрал вариант в

пока сам короче походу не догнал. Но суть в чем, просто хочу понять принцип инверсии зависимости. Пока сложно сказать что именно мне нужно тут...

прежде чем инвертировать заивисимость надо понять что является зависимостью

В нашем случае, зависимость - это IService?, ConcreteImpl использовали походу для того чтобы абстрагировать, зачем , не могу сказать

ага

Смотри. Классу Application нужно чтобы объект умел делать какие-то вещи. Для описания, что умеет объект придумали интерфейсы. Они не содержат реализации, только описание. Описываем интерфейс, содержащий нужные методы. Допустим IService. Таким образом получаем что классу Application нужен экземпляр IService. Например, пусть у него будет атрибут типа IService. Инверсия зависимости заключается в том, что если класс от чего-то зависит он не сам это создает, а получает зависимость снаружи. Таким образом, Application должен получить экземпляр IService в ините и сохраняет в атрибут Интерфейс сам по себе ничего не умеет, его нужно реализовать. Получаем класс ConcreteImpl. Дальше если нам нужен Application, у него есть зависимость IService и её тоже надо создать. Создаем экземпляр какой-нибудь реализации интерфейса. Например ConcreteImpl и создаем Application передавая этот объект.

хмм, начинаю догонять, запишу. Спасибо!

банду четырех читал?

В процессе. Советовали принципы SOLID и + банду четырех, решил после SOLID продолжить читать.

Но в пайтоне это все почти не работает))

иди нахуй

сильное заявление. ты фронтендер?