Отлично! Никогда, повторяю, никогда не видел, чтобы так просто и доходчиво кто-то объяснил сложные для понимания вещи, особенно для новичков. Речь, интонация, скорость - всё на высшем уровне. У тебя огромный талант. Прошу, пожалуйста, продолжай в том же духе публиковать уроки на тему разработки приложений на Spring framework! Спасибо
Огромное спасибо!!! Это лучшее, что я в целом смог найти для понимания DI и IoC. Все лекции и статьи, которые изучал до этого, кажется, опирались на тех, кто типа сразу понял, что это такое.
это лучшее что я видел по спрингу. начинал смотреть очень много, в том числе курсов и разных видео и книга по спрингу. нигде толком базово, на простых вещах не объясняется суть, везде предлагают как мартышке что то повторять без всякого понимания, как это работает, везде нарушается принцип от простого к сложному, сразу на тебя вываливают тонну непонятной ерунды.
@@maksymdobrynin нет предела совершенству, но ваша подача очень нравится. пересмотрел почти все собеседования. думаю это очень поможет в будущем. а по спрингу это конечно самые основы, но лучше и понятнее этого я ничего не видел. у Алишева может только что то подобное, но у него курс.
спасибо, хорошее обьяснение 👍. Скоро на собес, а спринг один раз только использовал, и то на тестовом для этого ж собеса, где не до разборов было - лишь бы программа работала) До этого даже не вникал что это такое и с чем едят
Макс, привет :) Большое спасибо за отзыв. По ссылке ниже наш скромный плейлист по спрингу. ruclips.net/p/PLxqzxxW1gWwIuSgG8od6N4LZg5V4kKp72 К слову, на этой неделе будет новый видос.
Xml то по сути просто все эти зависимости перенес в файл(текстовый) вместо new теперь используем теги(html). В коде чисто согласен, но под капотом трешь, особенно если у тебя редактор нет от jetbrains и не подсказывает зависимости. Spring boot вот это уже чистота кода, и думаешь только о бизнес логике, а не вот об этом "всем". Теперь можно сказать программист, а раньше xml-конфигуратор))) имхо. Молодец подача материала на высшем уровне
Лучше не употреблять слова типа «классик». Новичков в Java это сбивает с толку. То ли это какой-то термин на английском языке «classic», то ли что-то другое. Мне сразу стало понятно, что это уменьшительно-ласкательное слова “Class”. А за хороший ролик спасибо.
да, но нам при этом приходиться очень много делать настроек. Например если на внедрение в контейнер соответствует несколько классов, то возникает колизия и нежно опять таки в ручную это все конфигурировать, но правда на уровне настроек
@@Jetbulb это круто! Подача интересная. Единственное что по содержанию хотелось бы отметить, что DI и IoC не только ведь для уменьшения кода используются и дают создание зависимостей на откуп. На сколько я понимаю суть этой всей темы сделана для того, чтобы было проще оперировать зависимостями: есть интерфейс, условно, для чтения данных. И есть его реализации: а) для чтения с компа ; б) для чтения с облака. И суть DI и IoC для того и нужна, чтобы проще было в случае чего сменить реализацию с а) на б). Так как по сути мы заменим только реализацию интерфейса, а спринг сам создаст все нужные бины и тд.
Конечно, это не только про уменьшее кода в нашем приложении. Главная идея, отдать часть своей ответственности за процессы (конфигурирование, создание и последующие встраивание объектов) на фреймворк. Разумеется, это дает нам свободу при замене реализаций, поскольку если мы будем следовать ООП принципам, то мы легко сможем к уровне конфигурации выбирать нужную реализацию компонента, к примеру в таких средах: разработка, тестирование, продакшн. Очень немаловажный момент, что мы высвобождаемся от глубоких знаний информационной системы и как она работает. Наши компоненты становятся независимым и ориентированными только на свою конкретную задачу. Но главное, что мы просто описываем наши компоненты, показываем места где их нужно встраивать, а все остальное (конфигурирование, создание и последующие встраивание объектов) делает уже фреймворк. Собственно, это и есть "Инверсия управлени" или по другому можно назвать "Передача контроля", словно директор и его заместитель, который отвечает за что-то конкретное и результат выносит на использование директором. Ну собственно, Spring IoC Container отлично это реализует и применяет на практике.
Да. На отметке 29:55 сделайте тише. Там будет плохой звук на 10 секунд. Потом будет ещё один момент, но будет тише, чем в первом моменте. А так всё хорошо.
А inversion of Control это случайно не тоже что dependency inversion (не injection) ? т.е. в том смыcле что этот контейнер реализует принцип DI а не в том что мы отдаем контроль за созданием и внедрением зависомстей. Откуда информация что это именно так? Если бы это было про создание и внедрение заивсимостей то логичнее было бы назвать его dependency injection container
Стоит начать с того, что IoC - это принцип, а DI - его реализация. Инверсий управления много, к примеру «фабрика». Spring IoC-container - это название «спринговое» о чем можно почитать в их официальной документации и по сути является частной формой DI. Твои мысли от нелогичности названия и того, что по факту происходит справедливы, поскольку процесс выходит за пределы простого управления внедрением. Но «имеем, что имеем» 😅
Круто :) Спасибо, за такой классный вопрос. Да, все будет и мы уже работает над программой по Spring Framework и его частным случаям. Но все постепенно, мы пока ограничены в ресурсах. Наша цель - предоставлять как минимум 1 раз в неделю интересный контент для помощи в самообучении.
@@Jetbulb спасибо что ответили. Извините за такой может быть некорректный вопрос. А мы это кто? Вы школа или группа энтузиастов, и также планируете ли делать курсы полноценные до какого уровня? Заранее спасибо за ответ
@@AS-nu7ez Мы - небольшая команда из разных уголков мира, которая трудится на тем, чтобы начинающие специалисты в IT смогли быстрее и комфортнее устроиться на позицию своей мечты 😃 Под эту задачу и делаем бесплатный контент)
@A S, спасибо за желание помогать. Это же помощь не только нам, но и ребятам которые смотрят канал, ищут информацию. Отметку сделали, как только понадобится помощь, сразу свяжемся.
@@Jetbulb Допустим у меня есть спринг-проект. Есть стандартные компоненты с аннотациями Component, Servise и т.д. Но также есть другие мои объекты и объекты библиотечные, например RestTemplate. Эти объекты нужно также внедрять как компоненты используя аннотации Component и Bean или же просто создавать через new? Чем здесь стоит руководствоваться при принятии решения? Может быть есть книги хорошие на эту тему?
@@Das.Kleine.Krokodil Если мы говорит про IoC и DI, то создавать руками ничего не надо. За нас это выполняет Спринг. Если же речь идет о создании Бинов (компонент) из сторонних сервисов или где мы просто не может сами повесить аннотацию, то тут можно применить создание компоненты руками (через оператор new) и применять к нему аннотацию Bean. Во всех остальных случаях, создавать явно нет необходимости
По канализации вода не подается, если бы подавали, все бы сдохли от дизентерии. Канализация выводит продукты жизнедеятельности, а вода подается по водопроводу
Полезные знания про DI, но абсолютно невыразительные примеры. Раз уж промелькнула аннотация @ComponentScan, то почему бы не аннотировать конкретные классы @Component и не избежать использования ручного создания бинов для более выразительного примера? Создание бинов имеет смысл лишь при использовании «внешних» классов, либо когда требуется особая конфигурация перед использованием, а в указанном случае достаточно было аннотации @Component
@@АндрейСидоров-ц3ж вообще-то, нет. IoC - это принцип, а DI(Dependency Injection) - паттерн, то-есть более конкретная имплементация принципа IoC. В этом вопросе автор не ошибся. Возможно, вы путаете DI с DIP, который тоже является принципом.
@@millfreedom странно с других видео, с которіми я более согласен. DI - не жёсткое наследование, то есть использование уже существующего функционала. Использование существующего функционала может быть реализованно ручками, путём создание обьектов, или же автоматически (по сути IoC). Я чего так считал.
@@АндрейСидоров-ц3ж я нічого не зрозумів з вашого останнього повідомлення, проте на ваш захист скажу, що IoC/DIP, а також їх імплементація DI доволі розмиті поняття і ходить багато суперечок про їх межі 😅
Отлично! Никогда, повторяю, никогда не видел, чтобы так просто и доходчиво кто-то объяснил сложные для понимания вещи, особенно для новичков. Речь, интонация, скорость - всё на высшем уровне. У тебя огромный талант. Прошу, пожалуйста, продолжай в том же духе публиковать уроки на тему разработки приложений на Spring framework! Спасибо
Наконец то. Единственное видео про спринг где все понятно. Снимаю шляпу. Спасибо.
Классная подача, объяснение, одно удовольствие такие уроки слушать и самое главное - приходит понимание! Спасибо!
очень доступно объяснено!) очень хорошо обговорены определения и вся последовательность взаимодействия в системе
Один из лучших людей которые могут объяснять так доходчиво!
Очень ценю доходчивую речь!
как много полезной инфы в одном видео, и такая шикарная подача
Это пожалуй - лучшее объяснение Ioc и spring container! Спасибо Макс👍👍👍
Супер, такого бы разжевывания по Spring и Hibernate еще! Молодцы
Сделаем😉
Огромное спасибо!!! Это лучшее, что я в целом смог найти для понимания DI и IoC. Все лекции и статьи, которые изучал до этого, кажется, опирались на тех, кто типа сразу понял, что это такое.
Огромный труд на самом деле. Красавчик, спасибо!
Ну блин, я всё это знаю. Непонятно, что нового я рассчитывал тут услышать😊 Пора мне самому такие видосы писать)
Но лайк поставил😉
Макс крут!!!!!!!!!!!!!!!!до сих пор актуально))
Подача супер! Очень хорошо разжеванно! Появилось понимание куда копать! Благодарю автора за вебинар!
Просмотрел) что-то законспектировал, ставя на паузу))) Спасибо! все хорошо понятно)
Сюда надо конспекты кидать с таймингамм
@@Das.Kleine.Krokodil хорошая идея кстати!))
Спасибо Вам, Максим за данный ролик. До просмотра была некая каша в голове по поводу Spring. Чувствуется скилл в речи, слушать приятно
Великолепный ролик! Спасибо, ставлю лайк
Согласен, коллега
Еще раз хочу поблагодарить за такую подачу темы Spring
Коротко и ясно! Отличное объяснение)
Максим, здоровско объясняете. Спасибо!
Вам спасибо, что смотрите нас)
Надо что ли комментарий оставить) спасибо за видео, будет круто, если вы продолжите выпускать ещё!
Спасибо большое за поддержку! 😊
Будем стараться)
Ооо!!! Какой прекрасный урок!))) Обязательно посмотрю другие Ваши уроки!) СПАСИБО!
Лучший, спасибо, мб запишусь на собес технический к тебе
это лучшее что я видел по спрингу. начинал смотреть очень много, в том числе курсов и разных видео и книга по спрингу. нигде толком базово, на простых вещах не объясняется суть, везде предлагают как мартышке что то повторять без всякого понимания, как это работает, везде нарушается принцип от простого к сложному, сразу на тебя вываливают тонну непонятной ерунды.
Спасибо за отзыв))
На подходе еще будут видео про спринг в нашем плейлисте.
@@Jetbulb у вас очень полезные и информативные видео.
Спасибо большое)
Хотя нам кажется, что мы иногда очень сильно недорабатываем.
@@maksymdobrynin нет предела совершенству, но ваша подача очень нравится. пересмотрел почти все собеседования. думаю это очень поможет в будущем. а по спрингу это конечно самые основы, но лучше и понятнее этого я ничего не видел. у Алишева может только что то подобное, но у него курс.
Парень ты крут, все как нужно по полочкам, спасибо большое
запиши еще видео по спрингу
mvc или SD JDBC а может их оба в 1 уроке
заранее спасибо
Спасибо!) Обязательно сделаем в ближайшее время)
@@Jetbulb так и не сделали?(
@@andr74b11 По спрингу есть видео, но пока не все темы расскрыты.
Времени не хватает :(
Спасибо тебе Макс! Отличное видео
Великолепная подача 🔥
Отличное видео! теперь понимания прибавилось! Спасибо!!!
спасибо, хорошее обьяснение 👍. Скоро на собес, а спринг один раз только использовал, и то на тестовом для этого ж собеса, где не до разборов было - лишь бы программа работала) До этого даже не вникал что это такое и с чем едят
Очень крутой урок
Спасибо за ваш труд!
Спасибо за поддержку!😊
Хорошее объяснение. Было бы круто, если бы давал ссылку на код с занятия.
Спасибо! Мне очень нравится форма подачи материала.
Можно еще добавить после , что есть вариант c + аннотации
Макс, привет :)
Большое спасибо за отзыв.
По ссылке ниже наш скромный плейлист по спрингу.
ruclips.net/p/PLxqzxxW1gWwIuSgG8od6N4LZg5V4kKp72
К слову, на этой неделе будет новый видос.
Лекция супер! Большое вам спасибо!
Очень полезно для начинающего, спасибо!
Господи храни джунов!🥺
хороший разбор! спасибо
Xml то по сути просто все эти зависимости перенес в файл(текстовый) вместо new теперь используем теги(html). В коде чисто согласен, но под капотом трешь, особенно если у тебя редактор нет от jetbrains и не подсказывает зависимости. Spring boot вот это уже чистота кода, и думаешь только о бизнес логике, а не вот об этом "всем". Теперь можно сказать программист, а раньше xml-конфигуратор))) имхо. Молодец подача материала на высшем уровне
капец просто супер
Отличное видео, буду ждать других туториалов по Spring ))
Скоро будет ещё порция)
@@Jetbulb 3 недели прошло😀
Два года прошло😂@@jollyroger2757
Лучше не употреблять слова типа «классик». Новичков в Java это сбивает с толку.
То ли это какой-то термин на английском языке «classic», то ли что-то другое.
Мне сразу стало понятно, что это уменьшительно-ласкательное слова “Class”.
А за хороший ролик спасибо.
Круто, спасибо!
да, но нам при этом приходиться очень много делать настроек. Например если на внедрение в контейнер соответствует несколько классов, то возникает колизия и нежно опять таки в ручную это все конфигурировать, но правда на уровне настроек
Ещё! Давай ещё1!! :)
Да, мы уже готовим серию по Spring))
Кто будет в наушниках смотреть - аккуратнее. Местами по ушам бьёт ахово. На суть не влияет, там всё доходчиво, а вот на комфорт...
Спасибо за отзыв.
Мы уже работаем над тем, как улучшить качество трансляций, для сбережения ушек и глазок 🙂
@@Jetbulb это круто! Подача интересная. Единственное что по содержанию хотелось бы отметить, что DI и IoC не только ведь для уменьшения кода используются и дают создание зависимостей на откуп. На сколько я понимаю суть этой всей темы сделана для того, чтобы было проще оперировать зависимостями: есть интерфейс, условно, для чтения данных. И есть его реализации: а) для чтения с компа ; б) для чтения с облака. И суть DI и IoC для того и нужна, чтобы проще было в случае чего сменить реализацию с а) на б). Так как по сути мы заменим только реализацию интерфейса, а спринг сам создаст все нужные бины и тд.
Конечно, это не только про уменьшее кода в нашем приложении.
Главная идея, отдать часть своей ответственности за процессы (конфигурирование, создание и последующие встраивание объектов) на фреймворк.
Разумеется, это дает нам свободу при замене реализаций, поскольку если мы будем следовать ООП принципам, то мы легко сможем к уровне конфигурации выбирать нужную реализацию компонента, к примеру в таких средах: разработка, тестирование, продакшн.
Очень немаловажный момент, что мы высвобождаемся от глубоких знаний информационной системы и как она работает. Наши компоненты становятся независимым и ориентированными только на свою конкретную задачу.
Но главное, что мы просто описываем наши компоненты, показываем места где их нужно встраивать, а все остальное (конфигурирование, создание и последующие встраивание объектов) делает уже фреймворк. Собственно, это и есть "Инверсия управлени" или по другому можно назвать "Передача контроля", словно директор и его заместитель, который отвечает за что-то конкретное и результат выносит на использование директором.
Ну собственно, Spring IoC Container отлично это реализует и применяет на практике.
Да. На отметке 29:55 сделайте тише. Там будет плохой звук на 10 секунд.
Потом будет ещё один момент, но будет тише, чем в первом моменте.
А так всё хорошо.
Спасибо
Определение SpringCore 1:02:24
А inversion of Control это случайно не тоже что dependency inversion (не injection) ? т.е. в том смыcле что этот контейнер реализует принцип DI а не в том что мы отдаем контроль за созданием и внедрением зависомстей. Откуда информация что это именно так? Если бы это было про создание и внедрение заивсимостей то логичнее было бы назвать его dependency injection container
Стоит начать с того, что IoC - это принцип, а DI - его реализация.
Инверсий управления много, к примеру «фабрика».
Spring IoC-container - это название «спринговое» о чем можно почитать в их официальной документации и по сути является частной формой DI.
Твои мысли от нелогичности названия и того, что по факту происходит справедливы, поскольку процесс выходит за пределы простого управления внедрением.
Но «имеем, что имеем» 😅
Какой у вас шрифт в idea?
Так было давно, что уже не упомнишь.
Наверное 14-16
Будут курсы для мидлов?
Разбор SpringSecurity?
OAUTH2.0?
Кэширование и т.д.?
Круто :) Спасибо, за такой классный вопрос.
Да, все будет и мы уже работает над программой по Spring Framework и его частным случаям.
Но все постепенно, мы пока ограничены в ресурсах.
Наша цель - предоставлять как минимум 1 раз в неделю интересный контент для помощи в самообучении.
@@Jetbulb спасибо что ответили. Извините за такой может быть некорректный вопрос. А мы это кто?
Вы школа или группа энтузиастов, и также планируете ли делать курсы полноценные до какого уровня?
Заранее спасибо за ответ
@@AS-nu7ez Мы - небольшая команда из разных уголков мира, которая трудится на тем, чтобы начинающие специалисты в IT смогли быстрее и комфортнее устроиться на позицию своей мечты 😃 Под эту задачу и делаем бесплатный контент)
@@Jetbulb понял, здорово. А можно как-то в ваш проект влиться и также помогать?
@A S, спасибо за желание помогать. Это же помощь не только нам, но и ребятам которые смотрят канал, ищут информацию. Отметку сделали, как только понадобится помощь, сразу свяжемся.
А в каком случае нужно создавать, а когда можно через new? Например для RestTemplate
Хм… вопрос не очень понятен.
Можешь плз уточнить?
@@Jetbulb Допустим у меня есть спринг-проект. Есть стандартные компоненты с аннотациями Component, Servise и т.д. Но также есть другие мои объекты и объекты библиотечные, например RestTemplate. Эти объекты нужно также внедрять как компоненты используя аннотации Component и Bean или же просто создавать через new? Чем здесь стоит руководствоваться при принятии решения? Может быть есть книги хорошие на эту тему?
@@Das.Kleine.Krokodil
Если мы говорит про IoC и DI, то создавать руками ничего не надо.
За нас это выполняет Спринг.
Если же речь идет о создании Бинов (компонент) из сторонних сервисов или где мы просто не может сами повесить аннотацию, то тут можно применить создание компоненты руками (через оператор new) и применять к нему аннотацию Bean. Во всех остальных случаях, создавать явно нет необходимости
@@Jetbulb спасибо
можно по спринг секьюрете)
Можно и нужно :)
Всему свое время. Будет!
Это не в укор, но иногда у меня возникает ощущение, что мне пытаются втюхать товар, ну прям без которого жить не возможно
По канализации вода не подается, если бы подавали, все бы сдохли от дизентерии. Канализация выводит продукты жизнедеятельности, а вода подается по водопроводу
ctrl на клавиатуре, а это control
ни о чем, жаль потраченного времени
Полезные знания про DI, но абсолютно невыразительные примеры.
Раз уж промелькнула аннотация @ComponentScan, то почему бы не аннотировать конкретные классы @Component и не избежать использования ручного создания бинов для более выразительного примера?
Создание бинов имеет смысл лишь при использовании «внешних» классов, либо когда требуется особая конфигурация перед использованием, а в указанном случае достаточно было аннотации @Component
Следует также добавить, что автор утверждает, что DI является реализацией IoC, ну вообще то наоборот))) А так довольно таки полезное видео.
@@АндрейСидоров-ц3ж вообще-то, нет.
IoC - это принцип, а DI(Dependency Injection) - паттерн, то-есть более конкретная имплементация принципа IoC. В этом вопросе автор не ошибся.
Возможно, вы путаете DI с DIP, который тоже является принципом.
@@millfreedom странно с других видео, с которіми я более согласен. DI - не жёсткое наследование, то есть использование уже существующего функционала. Использование существующего функционала может быть реализованно ручками, путём создание обьектов, или же автоматически (по сути IoC). Я чего так считал.
@@АндрейСидоров-ц3ж я нічого не зрозумів з вашого останнього повідомлення, проте на ваш захист скажу, що IoC/DIP, а також їх імплементація DI доволі розмиті поняття і ходить багато суперечок про їх межі 😅