Как все это будет работать, если конструктор класса принимает два строковых аргумента? Для понимания работы DI ориентировался на видео Евгения Борисова по Spring. В том же Spring есть возможность гибко управлять созданием конкретных объектов. Например можно указать, что значение для свойства можно взять из определенных мест. Можно указать приоритет, когда в контейнере есть два инстанса, которые реализуют один и тот же интерфейс. К сожалению, DI не решит проблему, когда зависимость классов описывает данные. Например: Склад -> Каталог -> Товар -> Свойство товара и т.п. DI, на мой взгляд, больше подходит только для сервисов, где объекты не имеют состояний. В этом случае можно убрать жесткую связь и дать DI внедрять инстансы на основе реализованных им интерфейсов, которые ты ожидаешь в своем конструкторе класса. Тогда мы можем в сервисе ожидать, что DI нам внедрит нужный репозиторий и нам не придется его создавать руками.
@@SeemsNerdy Ну так главная фишка спринга именно в ДИ. Хотя для Java есть и другие реализации. Мне бы хотелось лучше понять реализации DI в других стеках. Поэтому и задал вопрос про конструктор с двумя строковыми аргументами.
В любой реализации у тебя все сведется к каким-то идентификаторам одинаковых классов или их группировке и явном указании этих идентификаторов при вызове. Посмотри описание к ролику - там ссылка на гошный fx - в нем это сделано через теги name или group
Мой коммент не по теме. Хочу узнать планируется ли какой-то тутуриал по растику?:-) Помню, что на канале были видосики о растике. Сложилось впечатление, что в пользу Go сделан выбор
Спасибо за отличную тему. Но не совсем понятен момент связывания переменных или инстансов классов с конструкторами. Из видео следует, что связывание происходит только по типу. А как тогда быть, если к конструктору подходят несколько переменных одного типа которые есть в контейнере?
Пример на Kotlin'е это ж просто пример, поэтому я там такое не делал, но в том же FX - uber-go.github.io/fx/annotate.html#annotating-a-function То есть на каждую переменную можно навесить тег `name` или тег `group` и в зависимых инстансах уточнить по этому тегу какой конкретный инстанс нужен, а в случае с `group` можно вообще весь массив переменных этого типа запросить
Ну так, лайфтаймов статических понавешал и живешь себе нормально. А че делать если у тебя фреймворк диктует свои правила жизненного цикла точек входа итд?
Спасибо большое за материал, как всегда прекрасная подача. Много материла осознал благодаря твоим видео)
о кайф. прям то, чего мне не хватало несколько лет.
мегахорош, красиво объяснил, и пример самописного DI классный ❤
Спасибо за видео. Коммент в поддержку!
спасибо за видео) качество топ!))
Со звком обосрался немношк
людиииииии!!! Он вернулся 😃
Рекомендую классы обзывать Company, User, Project - что-то из реального мира :)
Новый UI Intellij просто кайф :)
Плюсую, глюковатый местами правда
Теперь заживу!
Как все это будет работать, если конструктор класса принимает два строковых аргумента?
Для понимания работы DI ориентировался на видео Евгения Борисова по Spring. В том же Spring есть возможность гибко управлять созданием конкретных объектов. Например можно указать, что значение для свойства можно взять из определенных мест. Можно указать приоритет, когда в контейнере есть два инстанса, которые реализуют один и тот же интерфейс.
К сожалению, DI не решит проблему, когда зависимость классов описывает данные. Например: Склад -> Каталог -> Товар -> Свойство товара и т.п.
DI, на мой взгляд, больше подходит только для сервисов, где объекты не имеют состояний. В этом случае можно убрать жесткую связь и дать DI внедрять инстансы на основе реализованных им интерфейсов, которые ты ожидаешь в своем конструкторе класса. Тогда мы можем в сервисе ожидать, что DI нам внедрит нужный репозиторий и нам не придется его создавать руками.
Я блин даже не знаю что сказать :) спринг уже как джанга для питона стала. Кароче это тот кейс когда фреймворк тебе диктует как жить
@@SeemsNerdy Ну так главная фишка спринга именно в ДИ. Хотя для Java есть и другие реализации.
Мне бы хотелось лучше понять реализации DI в других стеках. Поэтому и задал вопрос про конструктор с двумя строковыми аргументами.
В любой реализации у тебя все сведется к каким-то идентификаторам одинаковых классов или их группировке и явном указании этих идентификаторов при вызове. Посмотри описание к ролику - там ссылка на гошный fx - в нем это сделано через теги name или group
@@SeemsNerdy Спасибо!
спасибо за новое видео! уже не трясет от "бизнес логики"?)) Минск
в 2021 году меня волновала "бизнес логика", сейчас все изменилось :)
Мой коммент не по теме. Хочу узнать планируется ли какой-то тутуриал по растику?:-) Помню, что на канале были видосики о растике. Сложилось впечатление, что в пользу Go сделан выбор
Да конечно будет, руки чешутся про систему типов в расте рассказать.
@@SeemsNerdy понял принял, спасибо:-)
Когда по растику видосы?)
Будет обязательно
Спасибо за отличную тему.
Но не совсем понятен момент связывания переменных или инстансов классов с конструкторами.
Из видео следует, что связывание происходит только по типу.
А как тогда быть, если к конструктору подходят несколько переменных одного типа которые есть в контейнере?
Пример на Kotlin'е это ж просто пример, поэтому я там такое не делал, но в том же FX - uber-go.github.io/fx/annotate.html#annotating-a-function
То есть на каждую переменную можно навесить тег `name` или тег `group` и в зависимых инстансах уточнить по этому тегу какой конкретный инстанс нужен, а в случае с `group` можно вообще весь массив переменных этого типа запросить
@@SeemsNerdy благодарю!
Программирую на Rust, чет проблем какая то выдуманная 😁😁😁
Ну так, лайфтаймов статических понавешал и живешь себе нормально. А че делать если у тебя фреймворк диктует свои правила жизненного цикла точек входа итд?
отличная подача материала 🥲