Спасибо за видео! Кстати, в райдере есть сочетание клавиш, которое позволяет оборачивать выделенный код блоками, ифами, циклами и дефайнами. Нэймспэйсы тоже. У меня это ctrl + alt + t. Довольно удобно.
Хороший лайфхак с папкой проекта. Я делаю так же, только папка у меня называется _Game, если это игра, либо _App, если приложуха. Подчеркивание отсортирует папку, и она будет всегда первой в списке.
Благодарю за видео. Но я бы хотел попросить Вас для этого курса написать ещё видео с использованием готового фреймворка. Сижу вот смотрю, не совсем понимаю почему то или это, хотя тот же зенжект легко использую в своём проекте. Напишите видео, пожалуйста, как использовать суперлёгкие фреймворки типа Reflex и VContainer - цены вам не будет. А то их на словах все упоминают, а как использовать не знают :D
Немного благодарностей и критики. Сначала критика. Андрей, вероятно вам, будучи опытным разработчиком, уже сложно поставить себя на место новичка-джуниора и посмотреть на ваши видео его глазами. А снимаете вы именно для такой аудитории, ведь сложно себе представить мидла, для которого та же тема DI незнакома. Проблема в том, что нет последовательного рассказа от простого - к сложному. Сразу выкатывается пример, в котором много всякого напихано - теги, делегаты, словари, обобщения, приведение типов, transient, singleton, кортежи и т.д. И вереница методов, которая работает со всем этих хозяйством, причем не самым банальным образом. Для новичка это сложно, на осознание всех деталей уходит много сил, внимание рассеивается и основная идея просто теряется. Не хватает начального рассказа в чем идея и удобство DI-контейнера. И максимально простого примера его устройства, взаимодействия с ним классов-клиентов. Такого подхода, к сожалению, не хватает не только этому, но и некоторым другим материалам на вашем канале. Теперь благодарности. Спасибо, что занимаетесь этой работой по передаче своих знаний и опыта. В частности, тема dependency injection и DI-контейнеров с привязкой к Unity очень слабо освещена в Рунете. Хорошо и понятно изложенных материалов по ней на русском языке найти сложно.
Спасибо за отзыв! Да, профдеформация однозначно есть, ваш отзыв однозначно благотворно повлияет на дальнейшие материалы. Я часто переживаю из-за длины видео, все время кажется, что мало кто потянет часовые лекции о том, как все устроено. При этом, конечно, хочется сделать все максимально понятно
не понимаю претензий. Название видео - ПИШЕМ ... те предполагается что с темой вы уже знакомы. И пишется КОНКРЕТНАЯ реализация, если она кажется сложной, запутанной, то никто не мешает написать свою, понятную. И у вас получится другой код, который реализует ту же самую идею
А надо ли NonLazy реализовывать? Или сервисы, на которые никто не ссылается в DI контейнере и не нужны и их можно где-то отдельно создавать, что думаешь?
NonLazy фактически то же самое, что и RegisterValue(), только инстанс снаружи контейнера создаётся, а не внутри. Оцениваю это как вкусовщина. Мне понятно, что есть регистрация инстанса, то есть могу создать объект и зарегать его - с параметрами или без, так зачем ещё NonLazy? Вроде как дублирование, но кому-то так удобнее
17:30 лучше логику работы с резолвом регистрации вынести непосредственно в регистрацию, либо выделить в отдельный метод/класс. Инкапсулировать эту логику необходимо. Странно, что владелец этой регистрации занимается её редактированием, мы ведь сами документы не переписываем, этим занимаются другие люди, которых мы об этом просим Иначе мы можем слепить что-то не так и всё испортить.
Nope, сервис локатор работает по-другому. Контейнер в базовом виде похож на сервис локатор, это правда, но принцип работы разный. Наверняка, вы ожидаете инжектирования как в zenject, однако, это уже апгрейды, а не базовый паттерн
Не понял, при чем тут время жизни? И Сингл и Трансиент могут жить одинаково долго. Их отличие же только в количестве инстансов. Вот Lazy и Eager еще можно было бы натянуть на разное время жизни
Это крайне куцый DiContainer, мало чем отличающийся от сервис локатора и так как все разрешения зависимостей нужно делать вручную, это сводит его пользу к нулю. В плане обучения, возможно, не самый плохой вариант, но использовать его я бы не стал. Зенджект в разы проще использовать
@@gamedevlavka просто не используешь, что считаешь лишним. Это всяко лучше, чем изобретать велосипед, тем более, что тема максимально разжевана и написать свой полноценный контейнер вообще не проблема
@@DarkIllusoireесли работаешь в большой команде, то "просто не использовать, что считаешь лишним" - задача со звёздочкой. Если функционал есть, кто-то обязательно начнёт его использовать, даже если он во вред проекту. Поэтому, нет лишнего - нет проблем. К тому же, написать свой контейнер - дело на полчаса, и изобретать ничего не надо
В статике скрыт дьявол... Ладно, это я драматизирую. На самом деле статика не чистится автоматически, поэтому либо имеешь ссылки в статике и боль при переключении сцен, либо делаешь по человечески. Дочерний контейнер (тот что sceneContainer) уничтожается при переходе на другую сцену, и это происходит без какого-то человеческого вмешательства
@@gamedevlavka sceneContainer легче сделать монобехом на сцене,. Можно пример того, что нужно почистить в статике(Я реально не могу представить ради чего такой огород городить, что даже почистить статику сложней)? Обычно если сохранять что-то в файлик.
Это я к тому что разобрать по полкам Vcontaner для junior+ будет куда полезней в перспективе, я понял Вашу задумку что Вы хотели показать работу контейнера как такового в принципе.
Всё хорошо, но только то, что вы сделали - это не DI, а ServiceLocator. Самое важное для DI вы и реализовали - сам Injection. Плюс в этом контексте название Singleton некорректно. Singleton - это четко определенный паттерн проектирования, который в вашем случае не реализуется
Не путайте людей, пожалуйста. DI это действие, DI Container - паттерн. И локатор служб работает совершенно иначе. Ну а по поводу синглтона в видео было проговорено, что это не тот самый паттерн, от него берётся лишь идея единственно возможного объекта. К сожалению или к счастью, это название закреплено во многих библиотеках, где-то сокращённо .AsSingle(), где-то полностью, не мной придумано
@@gamedevlavka Service locator and DI Container seem more similar, both of them use a container to define dependencies, which maps abstraction to the concrete implementation. The main difference is how the dependencies are located, in Service Locator, client code request the dependencies, in DI Container we use a container to create all of objects and it injects dependency as constructor parameters (or properties). И эта разница описывается везде, где есть сравнение Di Container и Service Locator
@@gamedevlavka А то, что многие библиотеки позволяют себе неточное именование, не значит, что и в своей стоит так делать. Ну а AsSingle - вполне себе адекватное определение
То, что вы кинули как разъяснение и есть, то что происходит в видео. Контейнер создаёт все объекты по запросу из зарегистрированных фабрик То, что сингловый объект называют синглтоном - очень понятный термин, при общении с разработчиками, не вижу в этом ничего криминального. И в принципе другой терминологии не слышал
Это было очень интересно, спасибо)
Теперь поскорее бы всё это понять и так же уверенно в этом разбираться🗿, как разбираешься ты.
В следующем видео по проекту станет гораздо понятнее, зачем все это нужно)
@@gamedevlavka Очень жду следующее видео)
Спасибо за видео, жду следующего)
Буду вместе с тобой пилить игру.
Круто рассказываешь! Интересно слушать)
Всё ясно и понятно! Лайк тебе))
Спасибо за видео! Кстати, в райдере есть сочетание клавиш, которое позволяет оборачивать выделенный код блоками, ифами, циклами и дефайнами. Нэймспэйсы тоже.
У меня это ctrl + alt + t. Довольно удобно.
Спасибо за фишку с try/finally))
Спасибо за видео ! Начал смотреть
крутой видос. Теперь самому захотелось перетащить привычный диай из PHP Laravel и попробовать применить его на игродельческой практике
Хороший лайфхак с папкой проекта. Я делаю так же, только папка у меня называется _Game, если это игра, либо _App, если приложуха. Подчеркивание отсортирует папку, и она будет всегда первой в списке.
Да, так тоже удобно, но меня нижнее подчеркивание выводит из себя)
Спасибо за труды! Видео огонь!👍
Спасибо! Очень помог в этой теме)
Ждем продолжения. Видео огонь.👍
Крутешок! Спасибо!
Трудно, но надеюсь дальше станет понятней
я бы посмотрел как Андрей собирает звезду смерти - можно из лего =)
Ябсобрал)
Благодарю за видео.
Но я бы хотел попросить Вас для этого курса написать ещё видео с использованием готового фреймворка. Сижу вот смотрю, не совсем понимаю почему то или это, хотя тот же зенжект легко использую в своём проекте.
Напишите видео, пожалуйста, как использовать суперлёгкие фреймворки типа Reflex и VContainer - цены вам не будет. А то их на словах все упоминают, а как использовать не знают :D
Немного благодарностей и критики.
Сначала критика.
Андрей, вероятно вам, будучи опытным разработчиком, уже сложно поставить себя на место новичка-джуниора и посмотреть на ваши видео его глазами. А снимаете вы именно для такой аудитории, ведь сложно себе представить мидла, для которого та же тема DI незнакома.
Проблема в том, что нет последовательного рассказа от простого - к сложному. Сразу выкатывается пример, в котором много всякого напихано - теги, делегаты, словари, обобщения, приведение типов, transient, singleton, кортежи и т.д. И вереница методов, которая работает со всем этих хозяйством, причем не самым банальным образом.
Для новичка это сложно, на осознание всех деталей уходит много сил, внимание рассеивается и основная идея просто теряется.
Не хватает начального рассказа в чем идея и удобство DI-контейнера. И максимально простого примера его устройства, взаимодействия с ним классов-клиентов.
Такого подхода, к сожалению, не хватает не только этому, но и некоторым другим материалам на вашем канале.
Теперь благодарности.
Спасибо, что занимаетесь этой работой по передаче своих знаний и опыта. В частности, тема dependency injection и DI-контейнеров с привязкой к Unity очень слабо освещена в Рунете. Хорошо и понятно изложенных материалов по ней на русском языке найти сложно.
Спасибо за отзыв!
Да, профдеформация однозначно есть, ваш отзыв однозначно благотворно повлияет на дальнейшие материалы. Я часто переживаю из-за длины видео, все время кажется, что мало кто потянет часовые лекции о том, как все устроено. При этом, конечно, хочется сделать все максимально понятно
не понимаю претензий. Название видео - ПИШЕМ ... те предполагается что с темой вы уже знакомы. И пишется КОНКРЕТНАЯ реализация, если она кажется сложной, запутанной, то никто не мешает написать свою, понятную. И у вас получится другой код, который реализует ту же самую идею
Вроде понимаю зачем это нужно , но реализацию не понимаю. Скорее всего после применения станет ясно.
А надо ли NonLazy реализовывать? Или сервисы, на которые никто не ссылается в DI контейнере и не нужны и их можно где-то отдельно создавать, что думаешь?
NonLazy фактически то же самое, что и RegisterValue(), только инстанс снаружи контейнера создаётся, а не внутри. Оцениваю это как вкусовщина. Мне понятно, что есть регистрация инстанса, то есть могу создать объект и зарегать его - с параметрами или без, так зачем ещё NonLazy? Вроде как дублирование, но кому-то так удобнее
@@gamedevlavka ну в целом ты прав, инстанс же можно прям там создать
Все еще очень надеюсь на ДОТС =)
На канале есть видео с разбором того, что такое DI в целом? Просто здесь много непоняток, так как я начинающий в геймдеве и программировании в целом.
а почему не сделал через builder?
Дополнительно ещё билдер объяснять) я соберу контейнер в пакет, и там наверное билдер воткну и оптимизирую)
17:30 лучше логику работы с резолвом регистрации вынести непосредственно в регистрацию, либо выделить в отдельный метод/класс. Инкапсулировать эту логику необходимо.
Странно, что владелец этой регистрации занимается её редактированием, мы ведь сами документы не переписываем, этим занимаются другие люди, которых мы об этом просим Иначе мы можем слепить что-то не так и всё испортить.
Это же обычный сервис-локатор, а не DI контейнер
Nope, сервис локатор работает по-другому. Контейнер в базовом виде похож на сервис локатор, это правда, но принцип работы разный. Наверняка, вы ожидаете инжектирования как в zenject, однако, это уже апгрейды, а не базовый паттерн
Добрый день.
А сам код из данного видео где-то отдельно выложен, чтобы его можно было в IDE открыть?
Да, этот проект открыт:
github.com/vavilichev/mBuilding/tree/main/Assets/mBuilding/Scripts/DI
Singleton в DI это не паттерн проектирование а время жизни объекта
Верно
Не понял, при чем тут время жизни? И Сингл и Трансиент могут жить одинаково долго. Их отличие же только в количестве инстансов. Вот Lazy и Eager еще можно было бы натянуть на разное время жизни
@@playtobeangry ну это такое понятие. Я читал об этих вещах в книге DI for. NET
Это крайне куцый DiContainer, мало чем отличающийся от сервис локатора и так как все разрешения зависимостей нужно делать вручную, это сводит его пользу к нулю. В плане обучения, возможно, не самый плохой вариант, но использовать его я бы не стал. Зенджект в разы проще использовать
На вкус и цвет.. Мне Zenject не нравится использовать, слишком уж много ему можно
@@gamedevlavka просто не используешь, что считаешь лишним. Это всяко лучше, чем изобретать велосипед, тем более, что тема максимально разжевана и написать свой полноценный контейнер вообще не проблема
@@DarkIllusoireесли работаешь в большой команде, то "просто не использовать, что считаешь лишним" - задача со звёздочкой. Если функционал есть, кто-то обязательно начнёт его использовать, даже если он во вред проекту. Поэтому, нет лишнего - нет проблем.
К тому же, написать свой контейнер - дело на полчаса, и изобретать ничего не надо
@@DarkIllusoire а вы могли бы дать ссылку на источник, где эта тема максимально разжевана (желательно на русском)?
У меня вопрос простой - чем так плохо сделать static инстанс и не городить весь этот огород?
В статике скрыт дьявол... Ладно, это я драматизирую. На самом деле статика не чистится автоматически, поэтому либо имеешь ссылки в статике и боль при переключении сцен, либо делаешь по человечески. Дочерний контейнер (тот что sceneContainer) уничтожается при переходе на другую сцену, и это происходит без какого-то человеческого вмешательства
@@gamedevlavka sceneContainer легче сделать монобехом на сцене,. Можно пример того, что нужно почистить в статике(Я реально не могу представить ради чего такой огород городить, что даже почистить статику сложней)? Обычно если сохранять что-то в файлик.
Текстом я лучше не поясню, в игровом примере станет понятнее
Не досмотрел видео, но описание похоже на Zenject. )
Ну так Zenject это DI контейнер)
@@gamedevlavka ну реализации разные бывают же. )
Скорее бы новый ролик с единой точкой входа! Ты будешь через экран загрузки делать?
@@txcslmв следующем видео ещё нет, прикрутим экран через одно видео
Все ваши видео достаточно интересны и познавательны, но я вот тут не понимаю если есть Vcontainer зачем придумывать опять свой?...
Я не придумывал ничего нового, показывал то, как в принципе работает под капотом типичный контейнер
Это я к тому что разобрать по полкам Vcontaner для junior+ будет куда полезней в перспективе, я понял Вашу задумку что Вы хотели показать работу контейнера как такового в принципе.
туплю с лямбдами, где можно их понятЬ?)
Похоже что это задача для Лавки Разработчика)
я правильно понимаю, что пока говорит Андрей слева - Андрей справа подгружается через асинхронный web request?
Так и есть, меня двое, иначе я бы ничего не успевал
@@gamedevlavka ну наконец то! Асинхронный Андрей is here!)
Почему у всех такой микрофон? Он типа кайфовый или просто на хайпе?
Ему года 4, может 5) тогда был недорогой относительно и качественный. Да и выбора тогда было сильно меньше, чем сейчас, сейчас бы я другой выбрал
Всё хорошо, но только то, что вы сделали - это не DI, а ServiceLocator. Самое важное для DI вы и реализовали - сам Injection. Плюс в этом контексте название Singleton некорректно. Singleton - это четко определенный паттерн проектирования, который в вашем случае не реализуется
Не путайте людей, пожалуйста. DI это действие, DI Container - паттерн. И локатор служб работает совершенно иначе. Ну а по поводу синглтона в видео было проговорено, что это не тот самый паттерн, от него берётся лишь идея единственно возможного объекта. К сожалению или к счастью, это название закреплено во многих библиотеках, где-то сокращённо .AsSingle(), где-то полностью, не мной придумано
@@gamedevlavka Service locator and DI Container seem more similar, both of them use a container to define dependencies, which maps abstraction to the concrete implementation.
The main difference is how the dependencies are located, in Service Locator, client code request the dependencies, in DI Container we use a container to create all of objects and it injects dependency as constructor parameters (or properties).
И эта разница описывается везде, где есть сравнение Di Container и Service Locator
@@gamedevlavka А то, что многие библиотеки позволяют себе неточное именование, не значит, что и в своей стоит так делать. Ну а AsSingle - вполне себе адекватное определение
То, что вы кинули как разъяснение и есть, то что происходит в видео. Контейнер создаёт все объекты по запросу из зарегистрированных фабрик
То, что сингловый объект называют синглтоном - очень понятный термин, при общении с разработчиками, не вижу в этом ничего криминального. И в принципе другой терминологии не слышал
@@playtobeangry сам себе ответил)