ООП вопросы на юнити собеседовании
HTML-код
- Опубликовано: 19 июн 2024
- Разбираем два ООП вопроса на собеседовании c# и unity3D. Чем отличается абстрактный класс от интерфейса и что такое принципы солид.
Ссылка на Discord - / discord
Группа Игроделов - special3d
Плейлист по паттернам проектирования - • Паттерны стратегия в u...
"00:00 - Введение"
"00:22 - Чем отличается абстрактный класс от интерфейса"
"03:44 - Принцип единой ответственности"
"05:55 - Принцип открытости/закрытости"
"08:40 - Принцип подстановки Барбары Лисков"
"10:42 - Принцип разделения интерфейса"
"12:15 - Принцип инверсии зависимостей"
Поддержка канала:
Patreon - www.patreon.com/user?u=32502669
В крипте:
BTC - 16WmTb4VTFGYrwEjjnMKNNMMzsMB1rPEqD
ETH - 0x8d35406f8317b846528d0a9ea4a34ce59968dff2
XRP - rLW9gnQo7BQhU6igk5keqYnH3TVrCxGRzm (TAG - 1438215071)
LTC- MNSWdzdVsUMnozSU5HhUPEscfxaUK3Fdck
#unity #солид #абстрактный класс #интерфейс #ityoutubersru
Что-то произошло при рендеринге и в видос не вошел еще одно отличие интерфейса от абстрактного класса:
Интерфейс не может содержать переменные или делегаты, в отличии от абстрактного класса. Извиняюсь за казус.
Все равно, ТЫ ЛУЧШИЙ!
Расскажи про лучшие практики применения тестов в юнити
с C# 8 интерфейсы всё таки испытали некоторые изменения..
docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/interface
docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#default-interface-methods
с Unity 2020.2 должна быть поддержка C#8 - docs.unity3d.com/2020.2/Documentation/Manual/CSharpCompiler.html
p.s Видео получилось отличное)
Во второй ссылке написано, что не поддерживается
@@gaitavr1992 , вторая ссылка это Whats new C# 8? - а что там имено указано не поддерживается? там вроде ничего нету про "не поддерживается"
Спасибо тебе, мужик! По-настоящему толково излагаешь - с практическими примерами и внятным объяснением без лишней воды. Сколько не пытался вообразить себе ситуацию применения принципа DIP, никак не выходило чего-то близкого к реальности, а тут отличный живой пример и доходчивое объяснение - сразу все разложилось по полочкам!
Делай еще, будем лайкать и комментить! Успехов тебе, человечище!
Чистая архитектура является хорошим примером для DIP
Спасибо за ролик. Часть этого я уже знаю, но вот научится это использовать еще предстоит )
Отличный ролик. Спасибо что делитесь опытом.
Очень классное и полезное видео. Вовремя я нашёл данный канал. Спасибо Вам!
Всё по делу , без воды. Дико плюсую.
Отличное видео. Хорошие примеры. Всё понятно и доступно.
Спасибо, очень полезно и познавательно, и отдельное спасибо за примеры)
Отличный видос, ОЧЕНЬ доходвчиво, спасибо!
Полезно!
Спасибо, Максим!
Очень сильно не хватает вот такого понятного контента по чистой архитектуре, и довольно важным вещам, как SOLID и OOP в частности. Да еще вполне себе таким приятным языком. Хотя, в силу малого опыта, конечно, понятно не все, но уже куда более полезно, чем многое из того, что было прочитано до. В общем, большое спасибо за ролик. =)
Потрясающее видео! Спасибо!
Видео супер, спасибо! У нас на проекте тесты используются для валидации префабов юнитов - проверяем наличие анимаций, ивентов анимаций и т.д.
Спасибо за ролик!
Максим, вы мощный мужик! Очень качественный контент. Да, и весь канал.
То чувство, когда собес был неделю назад и был задан вопрос про отличие интерфейса от абстрактного класса)
Форменное совпадение
UPD: Как всегда все на высоком уровне! Стабильно черпаю информацию с этого канала, пересматривая ролики раз за разом)
Спасибо за лаконичное и информативное обьяснение!
О солид на ютубе инфы масса, но, лично для меня, твой видос оказался лучшим из имеющихся и самым исчерпывающим.
Очень грамотный разбор, в целом я и так это знал, но теперь знаю ВПОЛНЕ. :)
Очень полезное видео, лайк.
Всё по делу. Хорошие примеры.
Спасибо большое за ролик
Топ рубрика
Жесть как всё компактно. Каждую секунду приходилось останавливать, чтобы успевать записывать информацию. За 14 минут уложено примерно 1,5 часа лекций от других ютуберов. Круто
Чётко, коротко и понятно пояснил за SOLID.
Но нужно было бы это в название написать. Случайно нашёл твоё видео и не знал, что там будут принципы SOLID
Спасибо за видео
С таким классным объяснением, любое видео будем ждать от вас! Ещё такой вопрос, как от новичка, думаю будет интересен не только мне, какой уровень знаний требуется от Джуна юнити? И последний вопрос, видел у вас разбор проекта подписчика, будет ли в дальнейшем данная рубрика и можно будет ли в теории прислать вам репозиторий?
Уровень знаний одним предложением не описать. А рубрику продолжится, она самая популярная на канале
как успехи?
Привет, хороший ролик :). Запиши материал про написание тестов.
Идеальный контент для "продолжающих".
1) На пальцах объяснен каждый принцип
2) Показаны примеры применения
3) Рассказано, в каких именно случаях рационально не придерживаться
Отличный термин
Лучший)
Супер, спасибо
Ты лучший!
Шикарно
Хорошое видео.
Полезно как и абсолютное большинство видео на канале, лучше пересмотрите 2-3 раза)
Спасибо!
спасибо!
Материал - золото!
Интересно было бы послушать по корутины, их чрезмерное использование и как этого избегать. Лично я видел корутину запускающей Idle цикл которого ничего не делал, а просто крутился до тех пока стейт не сменится. Ну а еще и действия типа Move, Run и т.д. тоже все в корутинах были.
Аригато, Сенсей!
Онэгаи симас
Никогда не оставляю комменты, но видосы просто топчик!!! Особенно вкатили видосы по шейдерам, это шедевры!
Можешь больше типовых вопросов на мидл уровень? Было бы неплохо ещё всяких каверзных вопросиков насыпать)
Спасибо!
Видосы по шейдерам собирают намного меньше просмотров, и что самое главное время просмотра низкое. Большинству интересно не то, как это делать, а что в итоге получится
@@gaitavr1992 спасибо за ответ! Если надумаешь замутить свой курс по шейдерам, проектированию или любой другой теме, запиши, пожалуйста, мой контакт. Буду в первых рядах ;)
P.S. А вообще можно тебя в линке добавить или ещё где?)
Добавляй
@@gaitavr1992 не могу найти, не выдаёт в поиске, скинь, пожалуйста, ссылку
Я думал линк - linkedin. В фейсбуке тоже есть
Спасибо
Очень годный материал. Спасибо.
А, вообще, было бы интересно услышать о другой , порой, можно сказать бытовой, стороне собеседования и причинах приема/не приема на должность.
Например, разработчик слишком опытный и текущий лид ищет причины отказа боясь конкуренции. Либо слишком быстро учится, судя по предыдущему опыту, и по мнению собеседующих, очень скоро достигнет лимита возможностей в компании и убежит.
Наиболее общая формулировка вопроса, наверное, - нетехнические стороны собеседований, их значимость по отношению к техническим. Как-то так.
Это больше тема каких-то подкастов. Пока цель канала - повышать квалификацию разработчиков, которые уже начали свой путь
Кул!
топ
Лайк и коммент: а вот тут как жуниор ушел чесать репу. Но очень полезно!
Если ты не понял о чём здесь шла речь, значит ты не Junior.
@@malvislightfadynightgames2925 мне вобще не важно, жуниор я или не жуниор, я тех арт , мне важно грамотно взаимодействовать с клиентскими программистами, а длиной я не меряюсь, это для озабоченных.
@@MrArtrynk длиной чего?
@@malvislightfadynightgames2925 не важно, зеленого кита)
Отличное видео. Мог бы ты когда-нибудь рассказать про стандартные вопросы по математике для игровых разработчиков, задаваемые на собеседованиях?
Кстати редко, что-то выходит за рамки перемножения векторов. Но в целом идея хорошая, я думаю будет полезно
Отличное, видео. Спасибо. Такой вопрос: как в геймдеве с unit тестами? Я когда начинал свой проект, тоже их писал, но потом отказался, потому что тратил на них очень много времени (видимо, из-за плохой архитектуры проекта). Знаю, что в "обычном" программировании без них никуда, а как дела с ними в игровых компаниях?
Сложно обстоят дела) По чуть-чуть пытаемся писать и уже много раз они спасали от сломанной главной ветки
@@gaitavr1992 Мне тесты, часто помогали избегать глупых или не очевидных ошибок, но из-за плохо стиля программирования (большой связаности классов и постоянного рефакторинга) и постоянной смены функционала, они постоянно ломались. В общем, я опустил руки и сейчас на свой страх риск пишу без них. Знаю, что это не хорошо, но пока время дороже:)
Максим, вижу ты используешь и Visual Studio и Rider. По умолчанию в Visual Studio ключевые слова return, switch, case и т.п. - фиолетовые и не сливаются с другими ключевыми. В Rider же они синие. Не могу найти эту настройку в Color Scheme Райдера.
Не подскажешь как в Райдере это исправить? (чтобы return фиолетовым стал)
Я использовал VS тему вроде бы, сразу при установке
Тесты в Unity ты имеешь ввиду TestRunner или UnitTests?
Доброго дня. Підкажіть назву книги, яку ви озвучили у відео. Дякую.
Классно и четко. 👍 Просьба про сопрограммы, осветить необходимость кеширования YieldInstruction.
Познавательно. Но обратил внимание - в коде частенько используются Async. Тоже попробовал Async. В WebGL не работает категорически. Пришлось от новомодного асинхронного возвращаться к старым добрым сопрограммам. Они работают.
А интересно на мобильных платформах Async-код работает?
Было интересно послушать. Есть вопрос, откуда была получена информация, что виртуальные методы и свойства противоречат LSP? Спасибо.
Из опыта использования
@@gaitavr1992 в этом плане, на мой взгляд, опыт спорный )) но в целом, в видео здравые мысли и рассуждения
@@LegionerII конечно спорный, поэтому я в видео сказал сразу, что отказываться от virtual не стоит
"Виртуальные методы являются прямыми нарушением лисков" - как-то очень громко сказано..
В разделе про принцип SRP увидел грубое нарушение принципа ISP. Таймкод - 4:44
В принципе разделения интерфейсов речь идет о интерфейсе в широком смысле слова - как об API предоставляемый абстракцией/классом, а не о конкретных интерфейсах в языке C#.
Для джунов и слабых мидлов, конечно, уровень изложения материала в ролике можно считать сносным, но с профессиональной точки зрения некоторые моменты недопустимо слабые.
Де конкретно там порушення ISP?
Сначала подумал, что странно рассматривать базовые вещи типа «принципа работы корутины и порядка вызовов методов у MB» после высшего пилотажа с разбором паттернов, но потом вспомнил ролик с «простым» счетчиком fps :D
После ролика про async, await многие просили рассмотреть корутину в сравнении
@@gaitavr1992 это ни в коем случае не претензия. Упомянутый ролик про счетчик отлично демонстрирует, что в базовых вещах запросто делаются самые неожиданные и фундаментальные ошибки. Теперь буду с нетерпением ждать обещанный ролик!
А разве не добавили в C# дефолтную реализацию у интерфейсов для методов?
PS смотрю тебя, потому что интересно, сам на шарпах не прогаю почти)
В 8й шарп добавили, а в юнити нет
За весь свой опыт только в одном проекте юзали тесты а это около 5 лет 😅
Привет, ты прикольно объясняешь, у тебя есть возможность объяснить как правильно использовать ООП, я понимаю что это, но плохо понимаю как классно и правильно это использовать.
Привет, начни с простоты классов. Пусть они отвечают только за одну задачи. Если есть общее состояние и поведение - сделай родительский класс. Не делай публичные поля и не раскрывай реализацию сторонним классам
Все это хорошо. Но на практике в движке когда начнем разбирать ?
Что имеется ввиду - на практике в движке?
Я люблю спрашивать зачем мне нужна инкапсуляция и какие проблемы она решает... В ответ часто слышу заученные стишки про сокрытие и про private... и по большей части продают ценности абстракции...
Ну с инкапсуляцией всё просто - она даёт возможность иметь классу согласованное внутреннее состояние. Если состояние может быть изменено из вне, ты не можешь гарантировать его согласованность, а следовательно, не можешь гарантировать коректное исполнение. По сути, это защита, чтобы не выстрелить себе в ногу, но, например, на ней строится DDD парадигма, в которой очень приятно писать код, а потом - его читать.
Кто использует тесты в юнити? При каких случаях, для каких механик?
Пять лет сидел на плюсах, постепенно осваиваю C# и Unity. По привычке вошел в ступор на вопросе: чем отличается абстрактный класс от интерфейса: так и хотелось заорать в экран - ничем, интерфейс это и есть чисто виртуальный (читай абстрактный) класс! Но тут дошло, что это уже не плюсы...
Я тоже начинал с плюсов
Все отлично, вот только быстро и информацию не успеваешь осмыслить и запомнить.
И интерфейс и абстрактный класс (АК) наследуются. И интерфейс и абстрактный класс могут иметь методы реализации по умолчанию. Оба не поддерживают утиную типизацию. Интерфейсу однако позволено множественное наследование в C#. АК может иметь внутреннее состояние, интерфейс все-таки нет. Плюс в АК действуют всякие правила наследования: ложка от кружки, кружка от теплохода и т.д.
Можно сказать что интерфейс это сильно урезанный АК.
Реализация интерфейса по умолчанию появилась в 8м шарпе. Вы его используете в юнити? Интерфейс все таки реализуется, там нечего наследовать, хоть и двоеточие стоит
+
Ох, неужели еще где то на собеседованиях бывают такие вопросы?! Хотел бы я что бы мне такие задавали :))) Меня больше раздражает когда спецы по хантингу требуют решения олимпиадных задач у вайтбоарда и пофиг что ты никогда не будешь делать ничего даже отдаленно похожего на такую задачу. Так мне в кампусе майкрософт в редмонде нагрузили задачку на 30 минут которую я даже за компом дня два потом решал, а решение которое судя по всему они хотели увидеть подсказал доктор наук по математике и то не сразу )). Особенно смешно становится когда ты видишь что половина кампуса это индусы которые такой код пишут что ты там SOLID, KIS, DRY и так далее днем и с факелом не сыщешь, и вот спрашивается что это за методологии такие по подбору персонала? У меня друг что бы сменить работу (будучи сеньером с 10 летним опытом в экспедиа) 2 месяца олимпиадные задачки сидел решал и из 25 компаний только 3 дали офер. В общем радуйтесь если у вас на собеседовании спрашивают чем интерфейс отличается от абстрактного класса, потому что вы в раю и может быть куда как хуже!
У меня тоже друг хочет попасть в гугл и постоянно штудирует задачи
Що за книга?
like, repost.
да
рейд от GameDev
Можно еще про DIY Containers рассказать :)
Dependency Inversion - DI - инверсия управления
учите насколько возможно глубоко эти вопросы, с точки зрения практики, я уже 5 й собес праваливаю ....
Послушать бы запись реального собеседования.
Как-нибудь дойдем, это хорошая идея)
блин я константы также пишу через статику, правда нотацию Капсом не понимаю.
Половину сказанного вообще не использовал никогда. И делаю игры с прекрасной лёгкостью и скоростью, и ФПС никогда не был ниже 300.
Интерфейс может содержать конкретную логику
Я уже отвечал на подобный комментарий
"Звучит очень просто..."
А, да? ААААААААА
Только паттерн PIDOR, остальное не нужно
SOLID это, конечно, хорошо, но а мы будем дальше придерживаться принципа KISS))) (нет)
Отличная идея, кисс как раз сдерживает поток абстракции из трех принципов солид)
@@gaitavr1992 сделаю вид, что я это и имел в виду!
Нее, будем дальше лепить синглтоны) X_X
@@theoctan8569 не ругайся так больше
Это самое не освещённое место в сети...
я про общую тему проектирования ))
"За плечами 5 лет опыта, но они не знают зачем нужен интерфейс, не совсем понятно что они делали эти пять лет, ну да ладно" - господи, очередное чудо которое сейчас всех научит. Ну так вот, если человек не знает что такое интерфейс и при этом он пять лет программист то это означает что он умён и парадигмой интерфейсов он пользуется, просто он сам её изобрёл, просто не использует его в синтаксисе. Можно подумать "-это как?" так это вот так, в юнити реализовывать интерфейс можно не только через код. Доброе утро!
Яким чином інтерфейс можна реалізувати не через код?
Я как начинающий, ничего кроме текста с горой теории ничего не понял например
Это видео для тех, кто уже ходит по собеседованиям
@@gaitavr1992 все равно. Понимаю что полезно, но понять пока в таком режиме не получилось. Лайк и подписка. Может сможете это объяснить это для более не подготовленных ?...
Солид не нужен совсем начинающим, он только пудрит мозг и отвлекает от рабочего кода и умения решать задачи. Ну а отличие интерфейса и абстрактного класса это уже инструментарий языка и его нужно знать
5:15 Автор здесь сам себе противоречит. То увеличивается скорость разработки, то уменьшается.
Никакого противоречия, если у вас есть приемлемый опыт разработки, то должно было быть ясно. Если цель придраться без понимания темы, то мимо
@@gaitavr1992 Как следование принципам SOLID уменьшает скорость разработки? Улучшение сопровождаемости кода как раз-таки есть одна из целей SOLID, что наоборот ускоряет разработку при расширении проекта.
Правильно, игра в долгую. При прототипировании скорость разработки снижается
"Абстрактный класс наследуется, а интерфейс реализуется" - Что?!?
Почитайте про realization и generalization при построении uml диаграмм
Вообще не верные вопросы, вопросы должны быть из темы "Почему Юнити помойка?". Это очень большой класс вопросов которые расширяются и увеличиваются при изучении такой корявой, больной и хромой недосистемы как Юнити. Вот только малая часть вопросов по этой теме:
- Почему Юнити дает пользователю загружать модели и текстуры в редакторе, но не дает этого делать просто в билде?
- Почему интерфейс юнити построен коряво, с заданием фактических размеров элементов, а не относительных как в том же CSS, WPF, Авалонии и бесконечном множестве других вменяемых систем?
- Почему Юнити является не потокобезопасным, однопоточным убожеством тормозящим игровую индустрию?
- Почему Юнити изобрело свои корявые и тормозные event-ы вместо того чтобы использовать стандартные?
- Почему система ввода у Юнити настолько убогая для андройда что игры с отзывчивым и быстрым управлением просто нельзя создать из-за ощутимого инпут лага?
- Почему Юнити выкупает чужие ассеты вместо того чтобы базовые вещи изначально предоставить пользователю?
- Почему у Юнити одна из самых худших камер управления в редакторе? Для примера управления можно посмотреть на тот же Blender с удобным вращением камеры вокруг объекта, а не вокруг камеры как сделали эти три школьника
- Почему Юнити не разрабатывает на своем убогом движке игры как делает это тот же самый Анреал? Неужели эти три школьника поняли что создали самый дерьмовый движок на свете?
- Кстати сама Юнити на одном месте вертела все принципы Солид) Она по факту должна была дополнять низкоуровневые API по типу ДиректХ или ОпенГЛ, а она в наглую тупо их заменяет своей корявой реализацией. Почему?
- Почему дегенеративные разработчики плодят своей мусорной программкой кучу мета данных, вместо того чтобы создать 1 файл для конкретных типов файлов?
- Почему Юнити урезает системный класс и вырезает оттуда стандартный сериализатор?
- Почему Юнити не интегрировала возможность подключать без проблем nuget библиотеки?
И еще множество вопросов почему Юнити бесполезный кусок кода.
Знайшов відповіді на ці питання, чи вони риторичні?
ну шо - лайкайте кто тесты использует в юнити (((((: и дизлайкатей если не используете