Какое эпичное окончание видео :) А так, очень рекомендую всем новичкам. Эти вещи это не "странные" хотелки на собеседовании, это то чем мы реально пользуемся при решении рабочих задач
@@eloreneloreneloreneloreneloren архитектура призвана помогать работать, а не мешать. Когда разрабатывают гиперкеж - важно быстро получить результат. И очень гибко и быстро менять идеи. Без заложенных на подкорке привычек сделать это будет очень сложно. Да, там код не главное, но опыт любого практика показывает насколько тяжело потом бороться с неуместными костылями и плохой реализацией. П.с.: я хейтер гиперкежа, мне такое неинтересно
@@gaitavr1992 а важно ли помнить их реализацию на память? скажем так достаточно ли будет объяснять на пальцах? ну принципы работы. или надо зазубривать именно все от а до я? в реальной практике всегда же можно открывать рефлектор и посмотреть под капот, или опять же погуглить
@@shyxiaolong Я думаю об особенностях работы с памятью первое время надо просто принудительно застявлять себя соблюдать, а потом это будет происходить на автомате, в результате будет неважно будешь ли ты работать на гиперкеж или ААА проекте - тебе везде будет респект )
Вот так узнаешь подкопотное листа и психологически сложнее становится использовать, хотя и понимаешь что чаще всего это не повлияет на скорость настолько критично. ) Спасибо, было полезно, но придется еще пересмотреть. Мне честно говоря пока не сильно пригодились словари, тут или не было подходящей задачи, либо надо получше разобратсья в теме чтобы понять где это бы пригодилось прям на 100%.
круто, я пока ничего кроме массива листа и словаря не использовал. Но очень удивительно было узнать что словарь быстрее листа и ваще супер крутой такой!
Спсибо, интересно, но мне больше нравится использовать SortedList он упорядочен и реализован с помощью бинарного дерева, что на мой взгляд является оптимальным решением. А стек я использую для смены окон интерфейса, когда из одного открывается другое, то предыдущее прячется и ссылка помещается в стек. Такое решение конечно подойдет не везде, но для меня пока годится :)
на 10:26 не совсем понял. Разве мы не должны подбрасывать во второй стек только после его опустошения когда хотим извлечь очередной элемент? стеки пишу от верха ложим 1, 2,3 первый стек 321 --- второй пусто команда извлечь => перекинули получили пусто --- 123 и отдали 1 пусто -- 23 снова ложим 4 потом 5 54 -- 23 извлечь - не копируем отдаем просто 2, только если опустел должны скопировать иначе получим пусто --- 5423 и отдадим 5
Спасибо! Лучшее объяснение по структурам данных! Не понимаю, зачем было реализовывать стек и очередь на основе массива, если есть односвязный список, где алгоритмическая сложность добавления и удаления была бы всегда O(1). А здесь мы сталкиваемся с необходимостью периодически перераспределять память при добавлении и удалении данных, а так же проверками размерности массива. Почему разрабы такой реализации отдали предпочтение?
Спасибо за детальное объяснение! Особенно про перемешивание списка и HashSet. Использовал Stack в последнем проекте для реализации Undo/Redo функционала.
Максим, большое спасибо за такой качественный и полезный контент, очень хотелось бы увидеть видео об архитектуре игры в самом Юнити и продолжения темы паттернов. Если не секрет, то в каких студиях/компаниях ты работал? Какими проектами занимался?
Вопрос не по теме: оставил комментарий под этим роликом несколько дней назад. Потом, после того, как досмотрел видео, понял, что он был не совсем обоснованный и удалил его. Почему мне приходят уведомления, что на мой комментарий кто-то отвечает? Его же нет... Я даже перепроверил (благо, всего коментов 48 на данный момент) и всё равно не нашёл свой
Почему под капотом стека обычный массив если стек все время меняется в длине а массив не лучшее решение для динамичности размера? Если в стек всегда добавляются и удаляются элементы только с одной стороны (вершины) то двусвязный список ведь подошел бы лучше?
Стоило проговорить, что стэк и очередь реализуются как списки, а не как массивы. И что взаимодействие с их элементами (peek и dequeue) имеет О(1). Так как не было сказано, реализуются они как массивы или как списки.
Снова ничего не понял при такой подаче. Ты можешь как то спокойнее преподать мысли ? Или ты думаешь что все на твоём уровне ? Ты же учишь, а значит слушающие скорее всего менее опытны, чем ты. Можно же то же самое немного медленнее преподать ? Или тебя как коня не притормозить?? Ты сам попробуй посмотреть свои видео представив себя учеником по С#. Ты бы вывез такой напор ?
@@gaitavr1992 действительно, уже надоело пересматривать одни и те же уроки с пометкой "для начинающих", но от разных блогеров, хочется выходить хоть немного на новый уровень
Я тоже временами не успеваю за мыслью, но это скорее от инфы которая не известна, перематываю (иногда и несколько раз), но это же запись, нет проблем посмотреть в любое время. А смотреть 30-40 минут как-то накладно.
Максим, спасибо что делишься опытом и знаниями! Вроде фундаментальные вещи, а нюансов много.
Да вообще, я никогда не указывал размер будущей коллекции, т.к. не знал, что память для них будет выделяться новая, а старая летит в GC
Это очень сложно, но очень нужно. думаю нужно посмотреть несколько сот раз, что бы это усвоить. Спасибо Макс, ты лучше чем хауди.
Какое эпичное окончание видео :) А так, очень рекомендую всем новичкам. Эти вещи это не "странные" хотелки на собеседовании, это то чем мы реально пользуемся при решении рабочих задач
Это все понятно, просто людей смущают эти вопросы при отборе на какой-нибудь гиперкеж проект, когда не то что код, да само качество игры страдает
А что такое качество игры? Это бизнес, который приносит деньги, и чтобы наворачивать много фичей нужны знания глубже среднего так сказать
@@eloreneloreneloreneloreneloren архитектура призвана помогать работать, а не мешать. Когда разрабатывают гиперкеж - важно быстро получить результат. И очень гибко и быстро менять идеи. Без заложенных на подкорке привычек сделать это будет очень сложно. Да, там код не главное, но опыт любого практика показывает насколько тяжело потом бороться с неуместными костылями и плохой реализацией. П.с.: я хейтер гиперкежа, мне такое неинтересно
@@gaitavr1992 а важно ли помнить их реализацию на память? скажем так достаточно ли будет объяснять на пальцах? ну принципы работы. или надо зазубривать именно все от а до я? в реальной практике всегда же можно открывать рефлектор и посмотреть под капот, или опять же погуглить
@@shyxiaolong Я думаю об особенностях работы с памятью первое время надо просто принудительно застявлять себя соблюдать, а потом это будет происходить на автомате, в результате будет неважно будешь ли ты работать на гиперкеж или ААА проекте - тебе везде будет респект )
Круто! 🔥
Радуюсь каждому видео!
Лукас и коммент в поддержку автора канала!
Четко, коротко и крайне понятно... Сенкс.
В текущем проекте юзаю очередь, так как она мне показалась удобной при работе с паттерном команда.
Спасибо за новое Видео! Лучший канал в своем роде.
Вот так узнаешь подкопотное листа и психологически сложнее становится использовать, хотя и понимаешь что чаще всего это не повлияет на скорость настолько критично. ) Спасибо, было полезно, но придется еще пересмотреть.
Мне честно говоря пока не сильно пригодились словари, тут или не было подходящей задачи, либо надо получше разобратсья в теме чтобы понять где это бы пригодилось прям на 100%.
Достойный ролик. Тема ... данных раскрыта. )
Очень крутое видео, спасибо, жду продолжения.
круто, я пока ничего кроме массива листа и словаря не использовал. Но очень удивительно было узнать что словарь быстрее листа и ваще супер крутой такой!
Не совсем) Памяти он потребляет очень много
@@gaitavr1992 Как там было? "Сколько выигрываешь в скорости, столько проигрываешь в памяти"?)
Ага, всегда компромисс
А это хорошая идея про подробный разбор типов значения и ссылочных.
Спасибо, продолжайте, пожалуйста
Это супер-видео! Максим молодец)
Спсибо, интересно, но мне больше нравится использовать SortedList он упорядочен и реализован с помощью бинарного дерева, что на мой взгляд является оптимальным решением.
А стек я использую для смены окон интерфейса, когда из одного открывается другое, то предыдущее прячется и ссылка помещается в стек. Такое решение конечно подойдет не везде, но для меня пока годится :)
Познавательно, спасибо!
Как всегда топ!
блин бро какой же ты классный.....
на 10:26 не совсем понял. Разве мы не должны подбрасывать во второй стек только после его опустошения когда хотим извлечь очередной элемент?
стеки пишу от верха ложим 1, 2,3
первый стек 321 --- второй пусто
команда извлечь => перекинули получили
пусто --- 123 и отдали 1
пусто -- 23
снова ложим 4 потом 5
54 -- 23
извлечь - не копируем отдаем просто 2, только если опустел должны скопировать
иначе получим
пусто --- 5423 и отдадим 5
Спасибо!
Спасибо! Лучшее объяснение по структурам данных!
Не понимаю, зачем было реализовывать стек и очередь на основе массива, если есть односвязный список, где алгоритмическая сложность добавления и удаления была бы всегда O(1). А здесь мы сталкиваемся с необходимостью периодически перераспределять память при добавлении и удалении данных, а так же проверками размерности массива. Почему разрабы такой реализации отдали предпочтение?
Спасибо за детальное объяснение! Особенно про перемешивание списка и HashSet. Использовал Stack в последнем проекте для реализации Undo/Redo функционала.
Хорошее видео
Дякую за досвід
Спасибо.
Использовал словарь, лист, связный лист, и даже хэшсэт. Но стэк и очередь пока не приходилось.
Интересный опыт
Использую очередь для реализации пула игровых объектов в Юнити (чтобы не приходилось каждый раз создавать часто используемые объекты типа пуль).
Хорошее применение)
Максим, большое спасибо за такой качественный и полезный контент, очень хотелось бы увидеть видео об архитектуре игры в самом Юнити и продолжения темы паттернов. Если не секрет, то в каких студиях/компаниях ты работал? Какими проектами занимался?
В линкедин меня можно найти, проекты там не все указаны, но есть компании, должности и обязанности
Кто эти странные люди, кто ставит дизлайк 😅
Максим, спасибо за полезные видео 🙏🏻
Насколько я видел - у всех видосов на ютубе есть дизы, это нормально)
@@gaitavr1992 от этого никуда не деться)
Не понимаю, зачем на 3:00 делается +i после рандома. Это же рандом, при следующей итерации может выпасть тоже самое (учитывая +i )
чтобы не обрабатывать первые i элементов, которые уже были обработаны
Вопрос не по теме: оставил комментарий под этим роликом несколько дней назад. Потом, после того, как досмотрел видео, понял, что он был не совсем обоснованный и удалил его. Почему мне приходят уведомления, что на мой комментарий кто-то отвечает? Его же нет... Я даже перепроверил (благо, всего коментов 48 на данный момент) и всё равно не нашёл свой
пж ответь откуда ты взял реализацию метода RemoveAt у листа? Как еë открыть?
В ide есть декомпиляция
@@gaitavr1992 Но где? Единственное что я могу это в visual studio нажать ctrl и клик по имени метода и получу public void RemoveAt(int index); 🙁
Я райдером пользуюсь
Почему под капотом стека обычный массив если стек все время меняется в длине а массив не лучшее решение для динамичности размера? Если в стек всегда добавляются и удаляются элементы только с одной стороны (вершины) то двусвязный список ведь подошел бы лучше?
Там такой же принцип, как у листа. Удваивается capacity и все. Слишком часто это не должно происходить
Стоило проговорить, что стэк и очередь реализуются как списки, а не как массивы. И что взаимодействие с их элементами (peek и dequeue) имеет О(1). Так как не было сказано, реализуются они как массивы или как списки.
Я показывал реализацию стека и очереди, оба с массивами внутри
где сайфай джентуха на заднике?!
Как-то невольно начинаю скучать по рефакторингу...
На собеседование к Максиму нужно готовиться основательно...
Я один слышу воющего кота/ребёнка на 8:40???
Вполне возможно, ребенок тогда шумел в соседней комнате
@@gaitavr1992 Я уже подумал у меня шиза =) Спасибо за ролик, очень полезный материал. Ждём-с материал по графам и более сложные задачки)
Снова ничего не понял при такой подаче. Ты можешь как то спокойнее преподать мысли ? Или ты думаешь что все на твоём уровне ? Ты же учишь, а значит слушающие скорее всего менее опытны, чем ты. Можно же то же самое немного медленнее преподать ? Или тебя как коня не притормозить??
Ты сам попробуй посмотреть свои видео представив себя учеником по С#. Ты бы вывез такой напор ?
Почему-то большинство вывозит, может тебе еще рано?
@@gaitavr1992 может и рано. Может и тебе подробнее и не спеша ? ))
Сколько ролик будет длиться? 30-40 минут? Я рассчитываю на аудиторию с опытом. Для начинающих материала куча
@@gaitavr1992 действительно, уже надоело пересматривать одни и те же уроки с пометкой "для начинающих", но от разных блогеров, хочется выходить хоть немного на новый уровень
Я тоже временами не успеваю за мыслью, но это скорее от инфы которая не известна, перематываю (иногда и несколько раз), но это же запись, нет проблем посмотреть в любое время. А смотреть 30-40 минут как-то накладно.