Внедрение зависимостей (Dependency Injection) с GetIt во Flutter

[aamonster]

Берём педивикию и читаем: en.wikipedia.org/wiki/Dependency_injection#Constructor_injection
Т.е. у вас Dependency Injection была с самого начала!

[Yahhi]

Вы правы. Изначально в коде использовались Constructor Injection (кстати не везде, было и создание переменных прямо в классе). Тем не менее, в структуре виджетов специфичной для Flutter, такой подход нарушает принцип DIP (высокоуровневые модули не должны зависеть от низкоуровневых) и заставляет импортировать общие классы чуть ли не в каждый класс независимо от того, нужны они там или нет.
В результате отредактировала название поста: он про то, как пользоваться библиотеками, облегчающими использование DI.

[aamonster]

Важно понимать, что у контейнера по сравнению с более примитивными методами DI есть не только плюсы. Да, упрощается код, больше гибкость, удобней тестировать. Но по сути запись в единственном инстансе GetId – это глобальная переменная со всеми её недостатками.

[sshikov]

Да тут вообще такое впечатление складывается, что писавший не особо понимает, о чем пишет. Ну вот смотрите:

В применении Dependency Injection есть неоспоримые преимущества:

— объекты не зависят от конкретной реализации классов, которые им необходимы,
— нет нужды менять код объекта, если зависимый класс поменял что-то в своей реализации или был заменен другим,
— реализация принципа «Зависимость от интерфейса, а не от реализации»,
— возможность использования mock-объектов при тестировании.

Типа, четыре преимущества? А вот фигушки. Два пункта из четырех (первый и третий) на самом деле не преимущества вовсе, а принципы (из SOLID). Т.е. это описание того, как следует поступать, чтобы получить преимущество. А преимущества тут на втором месте и на четвертом — а именно полученная гибкость в реализации зависимостей (в том числе тестовые зависимости в виде моков). Гибкость — преимущество, зависеть от интерфейсов — способ его достижения.

[nikita_dol]

Во Flutter есть InheritedWidget (и построенный на этом пакет Provider).
Тоже инжект, но без синглтонов и с обновлением виджетов, которые от него зависят.

Зачем использовать GetX?

[Yahhi]

Для использования InheritedWidget потребуется context, а опять-таки если начать использование Bloc, MobX или чего-то еще для управления состояниями, то этот контекст туда пробрасывать — очень так себе идея.
Конкретно в рамках примера в статье можно было бы и обойтись InheritedWidget

[nikita_dol]

• Во всех ваших примерах есть контекст
• Пробрасывать контекст в бизнес-лоигку — плохая идея

[Yahhi]

Я про это и говорю. Если бы проект включал в себя Bloc и внутри bloc-класса потребовалось бы обращаться к SharedPreferences, InheritedWidget был бы плохой идеей, больше подошел бы GetIt или что-то подобное.
В случае с моим примером, дополнительные библиотеки для управления состояниями не используются, так что применять InheritedWidget можно, но на мой взгляд в данном случае какую библиотеку применить — дело вкуса, мне захотелось показать GetIt, и я редко работаю без Bloc или MobX в проекте, так что можно сказать, что уже привычка

[nikita_dol]

Я к тому, что тема "во Flutter" не раскрыта

[Yahhi]

Предлагаете продолжить еще парой-тройкой вариаций на тему: «Dependency Injection во Flutter с помощью InheritedWidget», «Dependency Injection во Flutter с помощью Injector» и т.д. по мере поступления новых библиотек и подходов?

[nikita_dol]

Flutter — это виджеты
Тема статьи "во Flutter"

Можно было написать "в Dart" или "в Dart без рефлексии" — ничего бы не изменилось

[Yahhi]

GetIt совместим с DartSDK, так что да, действительно можно было бы применить его и в других ситуациях вне Flutter. InheritedWidget будет специфичен для Flutter, потому что виджеты.
Я не ставила задачу сравнить разные библиотеки для DI, а пример все-таки написан на Flutter, так что не соглашусь, написать «в Dart» можно, но пример бы уже к заголовку не подходил.

[foreg]

Спасибо вам за статью, только как мне кажется, стоит упомянуть, что GetIt - это сервис локатор (о чём написано в readme файле библиотеки), а не DI

[Yahhi]

Вот чем мне нравится Хабр, так это тем, что в комментах я узнаю такие нюансы теории, о которых никогда не задумалась бы самостоятельно. DI и Service Locator — разные паттерны. Есть даже отдельный пост на хабре, в котором разбираются отличия.

На странице библиотеки GetIt автор ссылается на статью Martin Fowler martinfowler.com/articles/injection.html, в которой говорится об обоих паттернах: service locator и dependency injection. И упоминается, что они могут дополнять друг друга.

Dependency injection and a service locator aren't necessarily mutually exclusive concepts.

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

Вообще, пока писала этот коммент, я пролистала около 10 постов известных и не очень программистов про Dependency Injection и Service locator. В результате я могу сказать только одно с абсолютной уверенностью: речь идет об инверсии зависимостей (сокращается также DI) :)

[UdarEC]

Добавлю интересные мысли на этот счет

http://sergeyteplyakov.blogspot.com/2013/03/di-service-locator.html?m=1

[andey-pe]

Автор, советую посмотреть на библиотеки `injectable` и `injectable_generator`, которые
отлично работают с get_it и избавляют от необходимости вручную описывать зависимости