Спасибо за видео! Как же я проржался с комментария в коде на 9:07. От реакции какого-нибудь мидла и сеньора тоже пробивает))

Теперь хочется посмотреть как можно реализовать di контейнер :)

Ура, новое видео, спасибо за обучение!!!

Круто, очень понравилось сравнение DI&ServiceLocator. Особенно за прозрачность как раз в точку попали. Из-за "прозрачности" как раз и тестирование на DI легче, чем в ServiceLocator. Скажу лишь, что у меня в жизни есть 2 примера, где один мой знакомый Senior на проекте использует ServiceLocator, а я наоборот на своем проекте использую только DI. А разница только в том, что они не пишут ЮнитТесты и не пишут асинхронный код(он там не нужен) для проекта и из-за этого ServiceLocator им подошёл идеально, а у нас всё наоборот.

Братан хорош давай давай вперед контент в кайф можно еще вообще красавчик. Можно вот этого вот почаще?

Ты бог, я как раз к собесу готовлюсь благодаря твоим видео, я смогу быстро улучшить архитектуру кода

1. Большое количество зависимостей передаваемых в конструктор (или в метод подобный Init) это не проблема внедрения зависимостей, а проблема класса или этих зависимостей. Либо класс плохо продуман и много чего делает - нарушен SRP, либо зависимости как абстракции плохо продуманы. Тут надо разбирать функционал класса, декомпозировать его, либо продумывать абстракции его зависимостей. В том, что абстракции класса и его зависимостей плохо продуманы виноваты сами классы и используемые ими абстракции. ServiceLocator это лишь способ скрыть эту проблему. 2. В представленном ServiceLocator интерфейс IService не используется как дженерик, а используется как ограничение на дженерик-параметр. 3. Непонятно почему ServiceLocator противопоставляется Singleton. Более того, это противопоставление странное, ведь ServiceLocator это и есть Singleton. Вернее реализация ServiceLocator основана на реализации патерна Singleton. 4. В плюсы ServiceLocator над Singletor указано, что ServiceLocator работает через интерефейс и, соответственно, можно подменять регистрацию реализации. И тут возникает недоумение - ничего не мешает некому Singleton (см. пункт 2) тоже работать через интерфейс и подменять реализацию. Если имеется ввиду, что ServiceLocator это альтернатива внедрению зависимостей через конструктор (или метод Init и ему подобным), то и в конструктор можно передавать не конкретные классы, а интерфейсы, которые реализуют эти классы и, вуаля - тоже можно подменять реализацию. 5. DI это не альтернатива ServiceLocator. DI это подход, который позволяет управлять зависимостями класса. ServiceLocator это тоже DI. 6. ServiceLocator тоже может быть тестируемый. Перед запуском теста нужно будет зарегистрировать тестовую реализацию, а после теста - убрать её. Да, тут возникают проблемы при параллельном запуске тестов, но речь же не о проблеме параллельных запусков, а возможности тестировать классы при ServiceLocator. 7. Про гибкость ServiceLocator: этот антипатерн не имеет плюсов. Все его плюсы: скрытие плохой архитектуры приложения, скрытие того, что классы и используемые им абстракции плохо продуманы. В хорошем проекте нет таких недочётов, а значит ServiceLocator не имеет никаких плюсов. Это однозначный антипатерн. 8. В "пачке Singleton" тоже можно использовать интерфейсы и подменять реализацию (замечание частично повторяет замечания 4) DI это широкое понятие. Это не только проброс зависимостей через конструктор или метод наподобие Init. Это вообще технология управления зависимостями класса, когда класс не создаёт зависимости сам через new(), а получает различными способами его извне. ServiceLocator это тоже DI. Противопоставлять ServiceLocator и DI нельзя, т.к. ServiceLocator это вариант DI. Более того, внедрение зависимостей через метод Init это тоже антипатерн, т.к. в данном способе внедрения зависимостей есть проблема того, что до вызова метода Init объект находится в неконсистетном состоянии. Единственный годный способ внедрения зависимостей это через конструктор класса.

@sergeykazantsev1655

11 ай бұрын

1) Идея того, что большие конструкторы это следствие нарушения SRP и можно решить эти проблемы декомпозицией - мне интересна, пока не уверен получится ли это реализовать на практике, но подумаю над тем чтобы взять её на вооружение в следующем проекте. 2) Да, IService сделан специально, чтобы по ошибке не забиндить какой-нибудь GameObject. Это ограничение сделано специально. 3) ServiceLocator противопоставляется не Singleton-у, а группе Singleton-ов. Многие джуны, да и сам я когда им был или на тех же хакатонах всякие GameController-ы, WindowManager-ы, Player-ы и тд - делал их синглтонами и обращался к ним всем. ServiceLocator, как контейнер(да, вседоступный) - является всё же другим решением. Я не отрицаю что он синглтон, но лучше иметь один синглтон который собирает несколько сервисов воедино, чем несколько десятков. Поэтому идет противопоставление 4) Интересно, на каком сайте ты видел реализацию синглтона с использованием передачи его через интерфейса и регистрацию реализации. Я ни разу не видел чтобы кто-то делал синглтон таким хитрым образом. Да, теоретически это возможно, но работая на разных проектах с такой реализацией я не сталкивался. А вот с SL сталкивался и не раз. 5) Я уже говорил что у нас с тобой разное понимание терминов. В следующих видео я буду более методичен и не буду вводить в заблуждение. Тезис звучит так: "Service Locator является альтернативой DI-контейнеру". Так же считает Фаулер, и под EventBus я кидал статью где он объяснял почему так считает. 6) Я не говорил что SL невозможно тестировать. Я говорил что DI тестировать удобнее и нагляднее. 7) Ну тут нет смысла спорить. Я когда делал это видео много лазил на форумах и анализировал разные мнения. мне ближе стало мнение которое я озвучил в видео "SL - это паттерн который может вам помочь, а может и стать антипаттерном" 8)Уже говорили. Можно, но так никто не делает. По крайней мере в геймдеве.

@a.danilenko

11 ай бұрын

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

@sergeykazantsev1655

11 ай бұрын

Да, в любом случае спасибо, я благодарен за конструктивную критику. Я не люблю токсичное критиканство, когда комментаторы пишут что-то типа "я умный - ты дурак" - но спокойная конструктивная критика вполне приемлема :) В конце концов я не претендую на роль гения и знающего всё и могу где-то ошибиться, чего то не дочитать и тд. Так что твою критику я считаю полезной и интересной для рассмотрения

Спасибо! Хорошие у тебя видосы!

Спасибо за видео!

Лучший

👍

отличное видео, спасибо! Я уже в своём проекте реализовать EventBus по одно из ваших видео - проект стал действительно чище, чем был Хотел попробовать поиграться с локатором, но вот подумал, а если у нас есть автоматически доступ к вещам таким, как ZInject, который уже за нас полностью написан - бери и пользуйся - что отменяет необходимость его создания собственноручно - нужно ли заморачиваться с Сервис локатором?)

@sergeykazantsev1655

Жыл бұрын

Скорее не нужно заморачиваться, как я в обзоре и говорил - DI поудобнее будет. Но мне иногда на мелких проектах не охота разворачивать Zenject, вспоминать как делать все эти инсталлеры и тд, хочется чего то своего, пусть и не такого эффективного, но простого и практичного. Но, просто можно знать, что вот такой паттерн есть, что вот интересная идея - хранить все менеджеры как сервисы и выдавать их по интерфейсу и тд.

@alexsorokin8373

Жыл бұрын

@@sergeykazantsev1655согласен, был на работе один мелкий проект - туда пихнул zinject - так он занял там места больше чем остальные скрипты))

Хочу отметить, что на мой вкус словарь не по string, а по Type в реализации будет надежнее. (В коде все равно typeof().name используется)

@sergeykazantsev1655

10 ай бұрын

согласен, так лучше будет

Спасибо, а когда ориентировочно ждать видео про шину?

@sergeykazantsev1655

Жыл бұрын

Постараюсь в две недели уложиться, если не случится чего

Расскажите, пожалуйста, про MVP)

@sergeykazantsev1655

Жыл бұрын

Видео по MVP уже есть на канале)

неужели подводка к DI контейнерам ??

@sergeykazantsev1655

Жыл бұрын

Я думаю, в следующей игре до них дойду

А почему бы просто не переключаться между окнами, монобехами, компонентами. Помоему unity создавалось, чтобы меньше кодить на c# и больше кодить в editor. ПС: джун, умеющий проектировать архитектуру приложения с помощью паттерна DI, уже не джун...

@sergeykazantsev1655

7 ай бұрын

Так никто окна/монобехи/компоненты не отменяет. Просто не особо много получается логики в editor вынести. Особенно на средних и больших проектах А если выносить её в Editor-ы, то расплывается зона контроля. Если что-то где-то поломалось то не всегда понятно где искать проблему - в префабе или в коде.

а можно популярно объяснить, чем плохи синглтоны? все эту тему мусолят, строят из себя важных сеньоров, а по сути никто не говорит

@sergeykazantsev1655

4 ай бұрын

1) Синглтоны вседоступны. Это значит что ты из любого места кода можешь вызвать синглтон и что-то внутри него сделать, это портит вертикальную иерархию использования классов 2) Порядок инициации синглтонов тяжело контролировать. Если у вас под 15+ синглтонов, явно один синглтон будет инициироваться на основе другого, это значит что один должен проинититься строго раньше, а второй строго позже. Приходится либо Entry Point писать, либо Script Execution Order дёргать 3) При росте проекта становится проблемой так же время жизни синглтона. Если у вас несколько сцен - какие то синглтоны будут перетекать из сцены в сцену - другие нет. По коду понимания who is who не будет, так как всех их можно вызвать через SomeClass.Instance.

Сервис локатор от синглтона отличается - ничем, так как является dictionary - синглтоном, ни больше ни меньше. Причем, синглтон - тут лишний. И проблемы у сервис локатора, остаются теми же - использование сервис-локатора, внутри кода, что в свое очередь формирует сильную связанность и явную зависимость от сервис-локатора и не явное поведение, из-за того, что зависимости появляются внутри кода. Так как это представляется в видео, делать не нужно, а если делать как нужно - то сервис-локатор становится не нужным.

@sergeykazantsev1655

Жыл бұрын

К сожалению, не могу с вами согласиться. Во-первых. Помимо dictionary синглтона, все сервисы хранятся в нём по интерфейсу, в синглтоне с таким никто не парится. Во-вторых сервис локатор никак не способствует сильной связанности кода, что DI-контейнер, что сервис локатор в этом деле равнозначны, мы и там и там вызываем тот или иной сервис, их количество не меняется. В-третьих, про неявное поведение, ненаглядность и зависимости внутри кода я говорил в этом видео, я его сравнивал с DI-контейнером. В-четвёртых это что, получается сервис локатор в видео неправильный, а правильный сервис локатор никому не нужен? Зачем тогда вообще этот паттерн обсуждают, кто-то его пишет и реализовывает?

@DarkIllusoire

Жыл бұрын

@@sergeykazantsev1655 Это не важно, по интерфейсу или нет, синглтон тоже можно по интерфейсу сделать, никто не запрещает. Во-вторых, сильные связи образуются именно из-за того, что используется посредник сервис-локатор, и в отличии от Di-контейнера, вы не можете отказаться от его использования, не переписав весь код. Дело не в правильности сервис-локатора(я про такое не говорил), а правильное его использование, делает его бессмысленным. А что про проблемы, которые описаны в ролике и решаются с помощью сервис-локатора, на изи решаются инвертированием зависимостей и построение хоть какой-то мало-мальской архитектуры. Я не критики ради, а чтобы люди не забивали себе голову глупыми решениями

@sergeykazantsev1655

Жыл бұрын

Во-первых, да синглтон можно сделать интерфейсами, просто если вы так сделаете это уже не чистый синглтон, который все подразумевают как статический класс с доступом, а некая модификация. И да, сервис локатор в какой-то степени тоже является синглтоном, но его можно назвать и DI-контейнером, если убрать статический доступ. Так что я бы отличал один паттерн от другого а не нёс все в одну гребёнку :) Во-вторых, в видео я говорил и о проблеме вседоступности(08:47) и доп зависимости(10:25) , и потому в этом же видео я показал что это слабое его место и DI таки выгоднее будет. Ощущение как будто вы посмотрели первую минуту моего видео и начали писать комменты :) В-третьих архитектура может быть разной и опять же, если бы вы хорошо посмотрели моё видео то увидели бы, что сервис локатор проще для новичков и потому где-то удобнее будет использовать его, проблема доступа и зависимостей не успеет стать головной болью. Да, DI получше будет, но DI не является единственным решением. Те же синглтоны все называют злом и болью, но по моему опыту все игровые студии от мелких до крупных так или иначе его прикрутят. Так что это вечный спор "труЪ ООП vs дёшево и практично"

@DarkIllusoire

Жыл бұрын

@@sergeykazantsev1655 нельзя сервис-локатор назвать DI-контейнером, это максимально противоположные вещи; Я посмотрел ровно до того момента, когда дальше смотреть уже не имело смысла. Сервис-локатор не проще для новичков, это тот же синглтон со всеми присущими ему проблемами. И это, чтобы мы говорили на одном языке, Di - это принцип, Di-контейнер - это механизм, использующий этот принцип. Идеально для новичка, энтри-поинт + фактори, а синглтоны, сервис-локаторы это лишнее и бесполезное, потому как ничем от статической переменной не отличается по факту

@sergeykazantsev1655

Жыл бұрын

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