DI & IoC #1: Теория

[@The14Some1]

Первый человек в мире, которого можно комфортно слушать на 2х

[@TakemuraGoro]

Спасибо мил человек. 3 раза на ПХП слушал, так толком не усвоил. А тут все идеально легло!

[@juliusmalkov9620]

я начинающий разраб - смотрю и проект на работе в разы лучше понимать стал)

[@mozqoved]

Отлично. Просьба, если можно создавайте плейлисты. Было бы намного удобнее для всех.

[@JavaScriptNinja]

Сделаем плейлисты, как вы заметили - очень много видео сейчас заливаем, организуем все красиво через пару дней

[@z0uRChannel]

Илья, ты крутой! ОгроМЕННОЕ тебе спаибо за твою работу!!!

[@samana1407]

Вы невероятно здорово преподаёте информацию!

[@saint8283]

Блин, наконец-то нормальное объяснение. Хотя я больше по C#, но на C# ничего понятного не нашел о контейнерах IoC/ID.

[@bulatawx687]

Спасибо, понятно и познавательно

[@DmtrDkhnv]

Спасибо за классные видео! На 14 минуте просишь дать знать, если интересно про способы разруливания кольцевых зависимостей, ленивое порождение и фабричные функции. Даю знать - было бы очень интересно послушать!

[@владимирсенцов-р1ю]

Не надо так разруливать. Лучше переписать. А принцип очень простой. Вместо обьекта отдать кложур, который создаст нужный обьект.

[@БурниСлав-е7л]

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

[@Volk1700]

спасибо за данное видео! отлично объяснено

[@JeffeekChannel]

*Православный* способ проброса зависимости - через конструктор. На этом моменте выпал :D

[@demidovmaxim1008]

Спасибо Вселенских масштабов.

[@ILMIRazmach]

Спасибо, за контент.

[@khalexspbru]

Хоть где-то стрелочка разворачивается)

[@Xeon83]

Очень круто разложено, снимаю шляпу.

[@ssurrokk]

респект

[@denisbielishev]

Было бы интересно послушать про кольцевые зависимости

[@SerjLavrin]

В видео упоминается о том, что DI может помочь в разрешении проблем с циклическими зависимостями, и что фабрики в этом могут помочь тоже. Хотелось бы услышать об этом подробней.

[@ЕгорЛазука-й1э]

Спасибо

[@juliusmalkov9620]

отличное видео!

[@kumb61]

То есть ссылки эти объекты в конструкте подставляются на этапе компиляции?

[@Volk1700]

Климов Гений

[@dmitryez2808]

Супер

[@irafish]

спасибо!

[@daniilloban7511]

привет, есть что-то новое в этой теме? и как называется рисовалка для экрана хочу себе такую)

[@makarov.m.m]

О, да. Обжёгся как раз с window (и прочими браузерными объектами), когда в проекте резко понадобился SSR.

[@alexandrbalashov7543]

Можете ли порекомендовать библиотеку для поддержки контейнеров в проекте на vue? После не долгого поиска нашел inversify - будет ли это достойным решением или лучше поискать еще?

[@JavaScriptNinja]

Не вижу смысла во вью брать отдельную библиотеку

[@RedkeiGost]

Звучит так, будто инверсия зависимостей можно происходит при переходе с лапши на классовый фреймворк.

[@kidninjja]

Огромное спасибо за труд, вы очень интересный докладчик, узнал о вас после HolyJs :). У меня пожелание есть небольшое. Если у вас был опыт фп во фронтенде - расскажите пожалуйста о нём. Допустим мы сейчас используем на проекте fp-ts библиотеку в связке с реактом. Заранее спасибо!

[@nevaknowmanamesame5089]

Чем отличается Inverse of Control Container от Service Locator? Читал что Service Locator это плохо

[@JavaScriptNinja]

Сервис локатор: Эй ты, Машка, принеси мне половник, весы и амбарный замок Почему плохо: сервис имеет доступ к Машке и может запросить у нее ВСЕ ЧТО УГОДНО. Из объявления сервиса не понятно что ему нужно для полного счастья (только из кода) IoC: Машка: Сударыня, вот ваши половник, весы и амбарный замок, как вы и просили для работы. Я пошла Почему хорошо: Машка ушла и больше ничего предоставить не может. Все нужные зависимости объявлены сразу (к примеру как аргументы конструктора)

[@timur43378]

DIC Container можно использовать как Service Locator если инжектить его как зависимость. То есть плох не сам сервис локатор, а то как он обычно используется. Другой подход подразумевает, что мы инжектим не сам контейнер, а конкретные нужные зависимости, внедрением которых контейнер и занимается.

[@aglproject9611]

А где или как это можно увидеть в коде?

[@whoknows921]

AGL project angular, nestjs, spring mvc

[@mikhailzubtsov7746]

Не понимаю восторженных комментариев

[@владимирсенцов-р1ю]

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

[@JavaScriptNinja]

Для орм к примеру циклические зависимости это норма. Более того система импортов в es2015 изначально разрабатывалась с требованием корректно работать с циклическими зависимостями. А вот require с ними не дружит, да

[@владимирсенцов-р1ю]

@@JavaScriptNinja Я придерюиваюсь позиции, что их надо избегать. Например захотел выделить модуль в отдельный .jar файл, а тебе надо пол проекта переписать из за любителей внедрить через поле или сеттер. А подобное просто можно недопускать. Вынес требуемый фунционал в новый класс и в обоих классах спокойно его используешь. А то что в orm эта штука есть - кто сказал, что это правильно?

[@JavaScriptNinja]

@@владимирсенцов-р1юэто правильно потому что описывает доменную область. У книги много авторов, у авторов много книг

[@владимирсенцов-р1ю]

@@JavaScriptNinja Тут идет противоречие между обьектной и реляционной моделью. Тут делать нечего. Тем более скорее всего не придется выделять отдельный модуль или сервис в подобном месте.

[@SerjLavrin]

по-моему в некоторых случаях циклические зависимости никак не избежать. Пример про userService и companyService в этом плане достаточно хорошо. Аналогичное можно часто наблюдать и в декларациях типов, когда типы ссылаются друг на друга. К примеру, Офис является Сущностью. Но Сущность имеет информацию о том, на каком Офисе она была изменена. Таким образом, появляется циклическая зависимость между Офисом и Сущностью и наоборот.