делать, и наверное лучшее, что смог нагуглить, но всеравно выглядит не очень. https://netbasal.com/demystifying-the-dependency-inversion-principle-in-angular-a2daca9b05ee. Еще очень смучает тот факт, что например в монорепозитории в 2 либах хоть зависимости и будут идти в одну сторону, обе либы должны импортить классы друг из друга (Первая абстрактный, чтоб его реализовать, а вторая все что ей нужны из либы). Наверное для билда это не очень идея.
Если либы импортируют друг друга, значит пора заводить третью либу
третью либу для интерфейса? Щас нарисую
Если интерфейсы, то забейте, они в жс не компилируются и зависимостей не вызывают
интерфейс нельзя использовать как токен в DI, вот в чем проблема
А зачем нужен D inversion в angular? Ангуляровская DI решает 99% проблем которые решает Dependency Inversion. Так как сервисы в конструкторах это по сути просто типы, по которым строятся токены, которые можно заменить потом. Спрашиваю, так как пытаюсь понять для каких проблем есть смысл это применять. Я нахожу только в одном случае применение классической di
ну как. Есть модуль которому нужно заинжектить что то интерфейса А. Этот модуль должен описать что ему нужно, а не другой модуль, который описывает конкретный сервис. Конечно можно в DI ангуляра что егодно подсунуть. но это не совсем будет правильно по типам, и по архитектуре
Мне кажется, вам нужно сначала проработать проблемы которые хотел решить Роберт Мартин с помощью DI У нас практически не бывает таких кейсов, когда слабая зависимость по типам может помочь. Для тестирования, так как язык не строго типизирован и реализация в angular позволяет подкинуть любой тип - можно просто мок создавать от класса- partial/implements и тд.
Обсуждают сегодня