Комментарии 11
Однако, поступая таким образом, мы нарушаем один из принципов SOLID, а именно Single Responsibility.
SRP тут вообще не при чем. Если так хочется поговорить про SOLID, то это D – Dependency Inversion Principle.
Когда мы заменяем одну реализацию на другую, то тем самым нарушаем этот принцип.
Опять нет. OCP совершенно не про это. Он говорит о том, что надо разделять код на компоненты так, чтобы компоненты вверху иерархии не зависели от изменений в компонентах внизу иерархии.
Мне кажется вы перепутали OCP и Dependency Inversion принципы. Первый из них как раз говорит, что сущности должны быть закрыты для изменений, но открыты для расширений. В моем случае модуль Injectable - сущность, и если я буду заменять одну реализацию на другую, то нарушу OCP.
Нет, не перепутал. Почитайте Clean Architecture:
This is how the OCP works at the architectural level. Architects separate functionality based on how, why, and when it changes, and then organize that separated functionality into a hierarchy of components. Higher-level components in that hierarchy are protected from the changes made to lower-level components.
...
The OCP is one of the driving forces behind the architecture of systems. The goal is to make the system easy to extend without incurring a high impact of change. This goal is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components.
Это на уровне архитектуры. На уровне классов/модулей – это, в основном, наследование, хуки, композиция, декораторы и т.д. – все то, что позволяет переиспользовать код, не изменяя его.
Заменить мок на реальный репозиторий, когда он готов – это вообще не про OCP. Подстановка разных реализаций интерфейса через аннотации – тоже. Это же просто прямое следствие инверсии зависимостей: если мы зависим от абстракций, то мы можем подставить любую реализацию.
А то, что в injectable вы описали подстановку с помощью аннотаций, а не через `return isTest ? Mock() : Impl()` – то вы не сделали систему "закрытой для изменений, но открытой для расширений". Попробуйте, например, добавить еще одну реализацию или еще одну environment, не изменяя существующий код.
Ваш пример с isTest ? напомнил мне цитату из чистого кода "Каждый оператор наследования можно заменить с помощью наследования". Плюс у меня сейчас и так 3 environment. В Injectable сейчас всего их 3 и думаю этого достаточно.
По поводу SOLID - это не математические законы, которые могут быть описаны с помощью формул. Тут его каждый трактует по своему.
Ваш пример с isTest ? напомнил мне цитату из чистого кода "Каждый оператор наследования можно заменить с помощью наследования".
Да, только это здесь не при чем.
Плюс у меня сейчас и так 3 environment. В Injectable сейчас всего их 3 и думаю этого достаточно.
Хорошо, но к расширяемости кода это не имеет отношения.
По поводу SOLID - это не математические законы, которые могут быть описаны с помощью формул. Тут его каждый трактует по своему.
Если подходить с позиции: "Я художник, я так вижу", то да, всё так, и смысла дискутировать нет.
Да и «портянки» строк вида
Котенйер.bind<что-то>.to<что-то>.ПриТакихТоУсловиях(<куча_разнообразных_параметров>)
— тоже никуда не деваются. И, в лучшем случае, сгребаются в один файл, а то и разбрасываются по всему коду, так что хрен найдёшь.
Injectable позволяет избавиться от GetIt.instance на основе создания модулей или добавления аннотаций к классам. Это аналог Dagger и Hilt из нативы. Так же хочется сказать, что программирование - это не Хогвартс, и в коде никакой магии не должно быть
Ну, вы рассказали про теорию абстракции, но где сам пример? Из этих картинок я так и не понял как реализовать di во flutter, какие библиотеки использовать и т.д.
Похоже, что injectable и есть та самая библиотека, которой вы пользуетесь - https://pub.dev/packages/injectable. Может быть расскажите о том, какие у нее плюсы, какие минусы? Мб есть какие-то камни преткновения? Иначе, в чем смысл статьи? Если логически рассудить, то я либо знаю об injectable, а тогда я точно знаю о di и нужды в статьи нет; либо я знаю о di и не знаю о injectable, тогда это не к вам; ну и наконец, если же я не знаю ни о di, ни о injectable статья не даст полного понимания, ведь даже ссылки на библиотеку нет. Спасибо вам за материал, но постарайтесь в следующий раз раскрыть тему польностью.
Flutter: Мощь DI и Injectable