Dependency Injection, С#, Внедрение зависимостей, unity, gamedev 

Спасибо. 1. DI может решить проблему динамического изменения зависимости в процессе (изменить калькулятор урона в процессе игры)? 2. Метод "Construct" у Player - причины названия? Это личное или кто-то из умных дядек так советует? (из СИ я привык к Init) ПС: раздел "Dipendency Injection, главное" 5:52 - 6:39 (7:29) сильно сбивает с толку, понимание смысла DI распыляет, размазывает, я этот раздел просто пропускаю, ничего не теряя в понимании... Раздел "Inversion of Control, Инверсия потока управления" - вот главное, и по мне, должно идти вначале, как раз до 5:52 или вместо, потому что именно оно является основой DI и объясняет принцип DI :*

Интересная рекомендация :) Я наоборот себя постоянно фильтрую и стараюсь не растекаться мыслью по древу, а тут получается есть желающие еще больше подробностей и объяснений) Подумаю :)

Да, мне кажется тут не важно, внедряете ли вы его как интерфейс или как абстрактный класс, по структуре, раз вы можете вставить туда разные реализации, UpCasе-я их как базовый класс - всё ок. В DI нет строгого правила - ВНЕДРЯЙТЕ ТОЛЬКО ИНТЕРФЕЙС. Абстрактный класс я думаю что тоже пойдет

Да, я приблизительно так же DI понимаю.

В ближайшее время не планирую, уж слишком он массивный, надо самому тщательно его прокопать, да и вроде есть уже ребята которые неплохо его разобрали

Да, на практике чаще всего клавиатура самый очевидный сервис, но я решил что пример с сервисом расчёта урона более наглядный будет, ибо можно всё пощупать и посмотреть сразу же

@@sergeykazantsev1655 а подскажите пожалуйста такой момент. вы говорили что с ДИ код будет меньше без свитчей и тд. А потом когда показали код на 9.15 там и свич кейсы есть, и куча классов дамаджКалькуляторРендж... как показалось кода, стало больше, запутанней... мы прекрасно обходились классами. чет вообще не понял что же изменилось...

@@user-zs8nt8yk4e потому что на 9.15 тайминг показан Injector, который а) может быть похожим но чуть другим в плане реализации, а именно быть фабрикой (Factory) и реально в рунтайме по типу (type) или другим задачам - инстанциировать конкретный экземпляр DamageCalculator, и всеравно такой switch (type) будет, главное что он в Factory а не внутри Player (который не должен знать в данной задаче, впрочем может быть и другая задача и тогда Player будет не в конструкторе получать а скажем внутри иметь Weapon и от Weapon уже будет зависеть какой Calculator у этого оружия); или (б) это может быть статичный выбор зависимости (без switch, без решения подтипа) когда "геймдиз прототипирует" и тогда везде в конструкторы пойдет одинаковый инстанс (или одинаковый подтип инстанса) скажем SimpleDamageCalculator; p.s. а кода будет полюбому больше за счет Factory (и выбора) или даже за счет Interface-ов, это минус паттернов такого типа

плохо что нет целостного кода

С DI свичи всё ещё остаются, но эти свичи остаются только в одном месте: на самом верху где вы определяете класс который будет решать ту или иную задачу. Магия DI заключается в том, что классам которые получают зависимости абсолютно всё равно с какой конкретно реализацией они работают.

Я не до конца понимаю о нарушении OCP в каком именно классе вы имеете ввиду. Если о DamageCalculatorRange - то в нём я не вижу нарушения OCP. Если вы говорите об Injector-е, то да, если у нас постоянно будут добавляться новые калькуляторы, switch-case будет расти. Но все равно где-то должен быть класс который будет связывать конфиги и конкретные классы, скажет - "Если нам нужен урон с перепадом, надо использовать DamageCalculatorRange"

Что касается смены типа урона: как раз таки приложение конфигурировать не придётся, придётся писать только новые калькуляторы. Возможно, надо будет переделать интерфейс изначальный если будет много модификаторов, надо проанализировать ситуацию, но в целом мы стремимся именно к тому, чтобы при новом калькуляторе мы писали один новый класс и он хорошо работал с нашей написанной системой

@@sergeykazantsev1655 Да, именно про свитч кейс говорил. Спасибо за видосы, очень круто сделанные! :)

Мне пока не хватает компетенции чтобы про ECS рассказать так как ручками я его никогда не трогал и знаю только теорию. Но когда-нибудь я до него доберусь :D

CallculatorType в плеер не целесообразно передавать именно потому, чтобы Player не распухал. DI позволяет эту проблему распухания обойти. Решение с CalculatorType для метода Attack является плохим, на 04:25 можно посмотреть. На 08:28 есть сравнение старого и нового правильного плеера. Таким образом CalculatorType нам не нужен в методе Attack если мы с калькулятором работаем на уровне интерфейса)

DI это скорее архитектурный паттерн, который говорит о том, как работать с зависимостями в коде(внедрять на уровне интерфейса) Стратегия это более прикладной и поведенческий паттерн, который ту же механику использует для удобного переключения сервисов во время выполнения программы. Они действительно очень похожи, но DI говорит об организации зависимостей в вашем проекте, а паттерн стратегия это конкретное использование этого же механизма для переключения одного поведения на другое

В Init тип калькулятора приходит сверху и уже не так важно как именно. Тип калькулятора может прилетать по разному: с сервака/JSON-а/ScriptableObject-а. Наша главная задача обработать команду "Я хочу калькулятор А, выбери нужную логику обработки и расчёта". Ту самую нужную логику обработки и расчёта реализует Injector. Кто именно отправляет команду - там не важно Блин, походу надо написать демку, а то много таких вопросов поступает)

Да, в видео это я не объяснил, потому написал в открытом гите демку github.com/Haywaar/PatternDemoStorage/tree/main/Assets/Patterns/DIExample Injector является точкой входа - то есть стартовым скриптом который запускается в самом начале игры. Параметры CalculatorType берутся на основе стартовых конфигов - сейчас мы в самом Injector-е в инспекторе выбираем один из вариантов. Подразумевается что выбор того или иного калькулятора основан на конфигах которые прилетают нам откуда-то снаружи(условно гд потрогал настройки на сервере и мы их подтянули)

09:00. Player не знает с каким типом атаки он работает, ему это не нужно. О типе атаки знает Injector. Он помещает в Player какой-то тип калькулятора, а Player работает с калькулятором на уровне интерфейса и может не знать с какой конкретной реализацией он работает. В этом и есть идея DIP.

Да, к сожалению, требования подросли

У меня на канале есть рубрика "Паттерны на практике" где я пишу простые игры и выкладываю их на гитхаб и на примере игр показываю решения. Сейчас есть одна игра, там нет DI, он будет во второй игре, когда я до неё доползу :) Если кирпич на голову не упадёт через полтора-два месяца выложу игру)

@@sergeykazantsev1655 спасибо . . . но она вроде как на Unity, а гораздо больше юзеров работают с WinForms . .. поэтому желательно на них чтобы была игра.

Ну на WinForms я к сожалению не смогу написать игру, ибо я чистый юнитолог и пишу только на юнити :(

@@sergeykazantsev1655 если вы юнитолог тогда подскажите в какой среде разработки пишется обработка графики . . . с кодом понятно - визюал студия . . . а графика в какой среде пишется ? . . . и подскажите, пожалста, какое видео смотреть чтобы с нулю начать обучаться юнити

Юнити это и игровой движок и среда, в ней как в редакторе вы размещаете сцены и объекты и в ней же вы подключаете написанный код как некоторые компоненты. Насчёт курсов по юнити с нуля, затрудняюсь ответить, сам в свое время купил курс на юдемии 6 лет назад, но за это время многое могло измениться

IoC появился как следствие DIP. Можно сказать что IoC это часть DIP. IoC - это про поток управления, классы высокого уровня теперь не зависят от классов низкого уровня. DIP более широкое понятие, которое говорит не только про инверсию потока управления, но и про зависимость от абстракции

1. "DI как паттерн не имеет ничего с DIP" - к сожалению я с этим не могу согласиться. Очень важной частью DI как паттерна является внедрение зависимостей на уровне ИНТЕРФЕЙСА. А DIP говорит об организации кода на уровне АБСТРАКЦИЙ. Я уже не говорю о том что практически в любом материале по DI тебе в связку накидывают материалы про IoC который напрямую связан с DIP. 2. Можно ли использовать DI без интерфейса и прокидывать зависимости напрямую как конкретные реализации? Да, конечно. Но я бы разделял DI как паттерн(внедрение зависимостей на уровне интерфейса) и DI как простое прокидывание одних классов в другие. Если из DI убрать вот эту часть про "на уровне интерфейса" - что от него останется? Идея собирать зависимости в одном месте? А чем это отличается от какого-нибудь Entry Point да или тот же SRP можно сюда притянуть. Лично я не считаю простое прокидывание одних классов в другие паттерном, так же как не считаю что Фабрика - это паттерн. Абстрактная фабрика или фабричный метод - это паттерны проектирования. Фабрика - это класс который порождает объекты но в этом нет никакого шаблонного решения. Возможно вкусовщина

@@sergeykazantsev1655 Понимаете, то что вы называете присуще и сервис локатору, основная идея DI, что у вас появляется точка конфигурации вашего приложения, вы не размазываете конфигурацию по приложению, а собираете всё в одном месте. Объект перестаёт думать о зависимостях и как ему их получить, он либо их разрешает сам, либо делегирует это слою инициализации приложения(что в народе и зовётся entry point). Насчёт последнего абзаца, это и есть основная идея DI, зависимости в классе настраиваются в каком-то инжекторе или контейнере или каким-то фреймворком. Класс перестаёт думать как ему получить ту или иную зависимость, он просто перестаёт отвечать за это. А программировать на уровне интерфейсов это уже совсем другое, если класс зависит от абстракции, то ему и поставим конкретную реализацию под абстракцией, которую если что можно поменять в той самой точке приложения и не думать, а в каких ещё местах надо было это сделать. В общем, мне просто не нравится что в DI начинают рассказывать следствия этого подхода, DI - это про получение зависимостей, то что вы описываете в ролике это ioc-контейнеры. Тут же важно понимать само действие, классу их поставляют или он сам их запрашивает или вообще сам их создаёт. И про первый пункт, в этом и проблема, что рассказывают про ioc контейнеры, а не про DI как таковой. Как и говорил выше, ioc контейнеры это конкретная реализация принципа DI, но не DI как таковой. Просто часто наблюдаю ситуации, когда говорят про DI и сразу ответ, а это какой-то ioc-контейнер с именем X.

@@sergeykazantsev1655 Также стоит упомянуть, что в ролике вы рассказываете про проблему сильной связности, DI к этому отношение не имеет.

Ну я думаю что мы друг друга услышали но остались при своём мнении. Наверное можно назвать это вкусовщиной потому что разные источники будут говорить разное. С моей точки зрения ключевая идея DI именно в внедрении зависимостей на уровне интерфейса. Сервис локатор выполняет схожие задачи но несколько другим образом, вы это знаете Я не считаю что главная идея DI - "у вас все зависимости должны быть собраны в одном месте". Таким местом(классом) в которым создаются зависимости EntryPoint-ы да и тот же сервис локатор на этапе инициализации.

Я бы сказал так. DI-контейнер это и есть Injector. У обоих задача - прокидывать зависимости в классы через интерфейс. Но обычно под DI-контейнером подразумевается более сложная сущность, некий Injector на максималках или же прокачанный Injector. Задача Injector-а - внедрить зависимости в классы через интерфейс. Задача DI-контейнера - выбрать/сгенерировать зависимости и внедрить их в классы через интерфейс. В DI контейнере может быть много внутреннего функционала - фабрики для создания сервисов, контроль за тем, нужен ли кому-то сервис или можно его отрубить чтобы в памяти не висел, подкапотная логика прокидывания зависимостей как в Zenject-е, чтобы ты не ручками зависимости прокидывал а просто бахнул тэг [Inject] и оно само прокинулось и так далее. Так что в моём примере можно сказать что Injector это и есть DI-контейнер, только этот контейнер жутко урезанный и ограниченный

А в чем именно, с вашей точки зрения, di нарушает solid?

2,3,4 принципы. Так же, использование di и рядом не стоит с KISS/DRY. Так же, с моей точки зрения ООП идет нога в ногу с SOLID. Классы доджны быть инкапсулированы в ООП и иметь единую ответственность по SOLID?, но если мы будем что-то пытаться засунуть в закрытый класс, который должени иметь свою зону отвествунности через DI, мы просто теряем смысл писать на ООП и под SOLID. DI отлично в ECS системах впишется. А большинство потребностей "Внедрения зависимостей" решаются прямыми руками и использованием делегатов. Но может я и не прав.@@sergeykazantsev1655

Если у вас класс А содержит внутри себя класс Б, это не значит что он нарушает принцип единой ответственности. SRP он несколько про другое как мне кажется, он про то что методы, обрабатывающую одну конкретную сущность должны быть в одном месте. Это упрощает модификацию, так как не надо по всему проекту прыгать и про то чтобы организовать классы так, чтобы они не распухали.

Наоборот! DI это вся суть ооп и солида. Просто при прокидывании зависимостей ты должен привязываться не к конкретным реализациям, а к абстрациям. Это тебе дает огромную силу и гибкость. Процесс тестирования упрощается в разы.