Больше видео по подготовке к собеседованиям на моём бусти www.flenov.info/plus/index СРАЗУ ЗАМЕЧУ - я не давал определений в видео и не пытался дать развернутые ответы. Более подробно по каждому пункту рекомендую еще обратиться к документации. У тех же структур больше отличий и они могут быть не только в стеке, но и в куче (сюрприз), у них есть еще отличие - сравнение по значению... В общем видео не отменяет работы с документацией и книгами
Большое спасибо, за то, что поделились вашим опытом! Позвольте узнать, спрашивают ли на знание структур данных (дек, очередь, кольцевые списки) и как их реализовать на C#?
@@_A-M-A-D-E-U-S_ Ни разу не было такого. В основном практические задачи бывают, для эффективного решения которых нужно понимать разницу в списках и хешах, но это все. В теории не помню, чтобы спросили что такое стек
одно замечание: struct это value type и скорее всего будет храниться в стеке, но runtime себя не ограничивает этим и запросто может его поместить в кучу если посчитает необходимым.
@@vovanchik_ru4208 "посчитает необходимым" - там есть четкие правила, когда в стеке, а когда в куче. Локальная переменная для метода - стек. Переменная класса - куча. Это прописано в MSDN и это очень логично, если понимать, как код выполняется
02:38 Differences in interview questions for C# programmers based on location 05:16 Importance of understanding abstract classes for C# interviews 07:54 Abstract classes vs. Interfaces vs. Structures 10:32 Boxing-unboxing in C# and usage in methods 13:10 Understanding the need for IDisposable in C# programming 15:48 C# programming: Inheritance and Interface 18:26 Importance of design patterns and dependency injection 21:04 Key interview questions for C# developers Crafted by Merlin AI.
1. Абстрактные классы, классы, интерфейсы и структуры (отличие от класса - Value Type, хранение в стеке. ) данных. Сейчас и record-ы спрашивать начнут. 2. String Builder. 3. IDisposable. 4. Делегаты. 5. Множественное наследование. 6. Object - базовый класс (редко спрашивают) 7. SQL Injection. 8. Throw & Throw Exception (Ex). 9. Singleton (или другие) - как добиться этого. 10. Dependency Injection. 11. Async/await.
@@TinzZz94Да не, ты чего. Я после универа проходил собес, меня в основном спрашивали про основы языка, базы данных и посмотрели дипломный проект (я писал блог). Минут 20 все длилось и дали оффер по итогу.
@@murr_ka4374рад за тебя, меня спрашивали на вакансию тсжаера с зп 30к по асп.нэту, .нэту, тайп скрипту про который ваще нихуя не было, ещё и энтити фрейм прикрутили
Спасибо, иниересно. Про наследование от object спрашивают, чтобы потом поговорить какие его методы можно переопределить и как ( ToString, Equals, GetHashCode ). А Singletone при регистрации контекста, например используется.
По сути, почти все, о чем было рассказано в данном видео, задавали мне на собедовании в белорусских IT-компаниях, когда я в 2010 году устраивался на позицию жуионира без опыта работы на коммерческих IT-проектах. У некоторых технических интервьюверов также может встретитьcя фетиш на книги и они спрашивают "а какие книги по программированию вы читаете". Как правило, они любят книги типа C# via CLR или GoF Design Patterns.
@@evgenyjagushinsky6695 я пытался найти работу на сеньёра этой весной в РФ, вопросы описанные в ролике это детский сад по сравнению с тем что бывает спрашивают про сборщик мусора довольно долго, года с 2014 до 2021 все спрашивали всё и во всех деталях в Озоне кроме всех паттернов проектирования с их группировкой по назначению ещё спросили паттерны миграции на микросервисы (их вакансии правда уже полгода висят незакрытые - может и не хотели на самом деле нанимать)
@@glebfadeev9782 вся проблема в том, что за рубежом есть нормальное образование в сфере программирования. А у нас нормальных вузов всего 3-5(МФТИ, ВШЭ ....)
@@evgenyjagushinsky6695 наверное так и есть, если посмотреть вакансии на том же HH джун по мимо языка должен знать как минимум git и sql, а у некоторых там вообще жара docker, redis, kafka. Такое ощущение, что HR просто пишет весь стек который использует компания, но скорее всего джун этим врятли будет заниматься сразу после оффера.
Абстрактный класс: 1. Нельзя создавать объекты 2. Можно реализовывать свойства и методы 3. Позволяет объединить через наследование похожие по сущности классы 4. Абстрактрый класс именно наследуется, а не реализуется 5. Члены класса не обязательно должны быть public 6. Нет множественного наследования (относится ко всем классам) Интерфейс: 1. Содержит только объявление методов и свойств без их реализации ( в последних версиях можно реализовывать) 2. Методы и свойства обязательно должны быть public 3. Объединяет разные по сущности классы, имеющие одинаковые свойства и методы, определенные в интерфейсе 4. Именно реализуется, а не наследуется 5. Возможна множественная реализация
Достаточно хороший список из отличий, никто так много не затребует. Я так понимаю, про наследование ты подчеркнул в ответ на мое утверждение про множественное наследование? Оно должно быть в списке интерфейсов. Я сказал, что в С# есть множественное наследование и ничего не говорил про классы, а даже намекнул на интерфейсы. Интерфейсы могут наследовать один и более интерфейсов. А классы уже (как ты правильно сказал) реализуют это.
Аааа увидел, у тебя там ещё один комментарий был и ты его видимо удалил и написал мне свою версию. Интерфейсы содержат только объявления методов, а абстрактные могут содержать объявления, обычно на собеседовании этого достаточно. Ну остальное ты тоже правильно тут написал.
Смотря как ты это сказал. Я так понимаю, что ты говорил про классы. Посмотри это видео: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html Ну а если тебя послали за то, что ты сказал, что интерфейсы наследуються и говорил в этот момент про классы, то подозреваю, что это токсичная компания.
Соглашусь с автором по поводу опыта прохождения по собеседованиям. Если вас не взяли в одной компании на работе - не стоит особо отчаиваться. Если нужно - просто тупо ходите по собесам. Среди 10 компаний, где вы проходили собеседование, вы, наверняка, получите офер, как минимум, в одной компании.
В России такие вопросы мне задавали, когда я устраивался на джуна. Сейчас проходил на мидла, это было в блоке базовых вопросов, на которые если не отвечаешь на большую часть, то сразу с тобой прощаются. Так что если это реальные вопросы с собеседований в Канаде, то это вдохновляет :).
В Канаде спрашивают базовые вопросы, а потом идет обязательно практика на час. Я про сам процесс интервью говорил здесь th-cam.com/video/cEZyzKFGCfU/w-d-xo.html
@@Dev-lessons спасибо, посмотрю обязательно. У меня были базовые вопросы, потом более глубокие уже на понимание в том числе и самой .NET платформы, потом задачи - передали управление и нужно было исправит ошибки в коде, изменить реализацию или решить грамотно какую-то задачу с точки зрения архитектуры/читаемости/расширяемости прям в открытом проекте собеседующего и показать результат. Благо задачек с ЛитКода не было :).
Спасибо за контент, который ты делаешь. Двигать образование - это круто. Хотел бы отметить, что утверждение "все значимые типы хранятся в стеке" верно лишь от части. Корректнее было бы сказать "все значимые типы хранятся там, где применяются", поскольку поле класса, которое является значимым типом хранится в куче, рядом с самим классом. На мой взгляд, это важно понимать, когда речь идет об организации памяти
object спрашивают как раз таки в теме Boxing/Unboxing. Когда метод принимает object т.к. этот метод по какой-то причине не делали generic, то скорее всего ожидают передачи reference type и downcast object к нужному типу. Но можно передать и value type. например int и нарваться на Boxing (когда со стека переменная переедет в кучу).
Информация в видео полезная, спасибо! А вот со множественным наследованием немного факапнулся) интерфейсы мы не наследуем а имлементируем, в джаве это явно показали разными операторами extends и implements)
Я джава не знаю, а ты мог бы посмотреть комментарии, меня уже много раз пытались подловить на моей же уловке. Классы реализуют интерфейсы, но я даже намекал на множественное наследование интерфейсами. Интерфейс может наследовать другой интерфейс и тут ограничения на количество нет. Это именно наследование, а не реализация.
Это прописано даже в MSDN: @t Interfaces can inherit from one or more interfaces. The derived interface inherits the members from its base interfaces. И так далее
@@Dev-lessons давай начистоту. Ты не разделил понятия «наследование интерфейсов» и «наследование классов» это 2 разных понятия. Есть несколько вещей: 1. Наследование интерфейсов 2. Наследование классов 3. Реализация интерфейсов Ни в коем случае нельзя подменять понятие реализации интерфейсов наследованием, грубая ошибка, как по мне. Наследование интерфейсов - наследование контракта/расширение контракта. Наследование классов - расширение логики или функциональности классов. Реализация интерфейса - реализация контрактов. Был бы ты образован хоть немного, знал бы, что даже в UML диаграммах связи «реализация» и «наследование» имеют разные обозначения, ведь этому учат на первых курсах университета по софтварному инжинирингу. Но не буду тебя осуждать, если ты выбрал путь программиста, а не разработчика. Ты же пытаешься втюхать нам, что нет разницы между классом и интерфейсом, говоря, что реализация контракта = наследование. Или даже больше, что иерархия наследований = множественное наследование. А вообще оставайся при своём мнении, ведь ты для себя придумал правду, с которой тебе неплохо живётся.
@@Dev-lessons и на счёт комментарий, которые ты мне советуешь прочитать. Проблема в том, что ты читаешь свои комментарии изо дня в день не отходя от кассы. Написали, сразу прочитал. Через тебя проходи весь поток информации из комментариев. Поставь себя на мое место: я смотрю большое количество видео, где под каждым видео написаны тысячи комментариев, чтобы иметь право на своё мнение, я должен прочитать весь поток комментариев, не распределяя нагрузку, как это делаешь ты. Отсюда приношу свои извинения за то, что я не веду твой образ жизни, читая каждый день твои комментарии, все что я вижу это рекомендации ютуба по твоим комментариям, среди которых я не встретил ни одного комментария с обсуждением этой темы, вот и решил написать.
@@alexpermenev а причём здесь разделение понятий. Я в видео сказал, что в C# есть множественное наследование, но все думают только про классы. Потом я сказал про интерфейсы, но никто не состыковал это и пишут мне про наследование классов. Разделять наследование и реализацию нужно, потому что это разные вещи
Меня как-то на одном собеседовании очень жестко гоняли по книжке Рихтера (CLR via C#). Спрашивали зачем нужна CLR, для чего это всё? Для чего JIT и т.п.? И прям досконально, около часа. Не понимаю смысла таких интервью... А потом мне пришел отказ)) ну и ладно Или другая сторона медали - в собеседовании на миддла спросили про отличие абстр. класса от интерфейса, я рассказал (и не считаю что я не знаю разницы, это джуновский вопрос).
Не знаю, зачем спрашивают Рихтера и CLR. Это полезно знать для себя, но большинство программистов в реальной жизни эту информацию редко использует. Самая важная информация для всех это ссылочные типы против значений.
у некоторых технических интервьверов бывает фетиш на книги по программированию. Пример из жизни: в 2010 году я устраивался в IT-компанию на позицию жуниора без опыта работы в IT. Мне там сперва задавали практически те же вопросы, что прозвучали в данном видео. По некоторым вопросам я плыл. После этих вопросов интервьювер (он же начальник .NET-отдела) поинтересовался какие книги я читаю. Ну я ему на вскидку назвал пару книг, среди которых была знаменитая книга Рихтера. В результате мне сразу же сделали офер на жуниора с зп 500$ с испытательным сроком в один месяц. Аналогичная ситуация была и у других жуниоров, которые устраивались сюда. Пару месяцев спустя в эту же самую компанию устраивался на позицию жуниора парниша с опытом работы в IT в несколько месяцев. Его на собеседовании спрашивали практически все те же самые вопросы. В том числе и про книги. Он же ответил, что вместо книг предпочитает необходимую информацию гуглить в интернете по мере необходимости. Такой ответ не понравился нашему начальнику .NET-отдела. Скрипя сердцем, парнишу все же взяли на работу, но с испыталкой в три месяца и зп 300$ (вместо стандартных 1 месяца и 500$). Мурыжили парня 3 месяца испыталки, которую он прошел и после ему предложили повышение зп до 350$. Но т.к. парень оказался вундеркиндом по программированию, его такой расклад дел не устроил и он устроился в другую IT-компанию, где ему сходу предложили 800$ зп. А спустя пару месяцев он уже там получал 1600$. Год спустя он поменял место работы и там уже имел зп в 2500$. Вывод: фетиш на книги способен не позволить разглядеть талант специалиста.
1. Record ведут себя иначе при сравнении - это важно! var person1 = new Person("Tom"); var person2 = new Person("Tom"); Console.WriteLine(person1.Equals(person2)); // TRUE!!!!!! Сравнение идет на основе значений!
Это происходит не потому, что объекты record чем-то особенные. Просто в них переопределены методы сравнения и некоторые другие. По сути, это просто удобный синтаксический сахар.
Добавлю из своего опыта прохождения собеседований вопросы, которые задавали мне, может кому-то будет полезно: 1) В чём разница между абстрактным классом и интерфейсом, примеры использования. 2) Разница между анонимным типом и кортежем? 3) Разница между finalizer и disposable? 4) Расскажите про принцип работы GC - поколения и графы объектов. 5) В чем разница между throw без параметра и с параметром? 6) В чём основная фишка словаря? 7) В каких случаях уместно использовать монитор, а в каких мьютекс? 8) Сколько способов создания потока существует, и перечислить с примерами реализации.
@@Dev-lessons Я использовал. Все просто. Некоторые классы которые реализуют интерфейс могут не реализовать один или более методов (свойств), и тогда будет ошибка. Тогда поможет реализация по умолчанию.
@@redfox7193 Если такое случается, значит инерфейс перегружен, и имеет слишком много функционала, который не всем необходим. В таком случае лучше разделить интерфейс на несколько. Довольно грубо делать контракт, который должен давать гаранитю наличия некоторого поведения, и в итоге не давать реализацию этого поведения. Это кстати как раз является нарушением одного из принципов SOLID. I - Interface Segregation Principle (принцип разделения интерфейса).
Вы на времени примерно14:30 говорите про искъюлинг джекшен, верно? Не совсем расслышал. Можете написать как правильно звучит? Интересный вопрос наверно, надо бы ознакомиться с ним. Ещё про дипендент сигжекшен, верно услышал, он именно так называется? И почему строку конкатенацией аж ЗАПРЕЩЕНО собирать, если такая возможность в языке предусмотрена? Заранее спасибо!
1. Struct vs Class мой любимый вопрос на собеседовании, на нем плывут 70-80% жунов и мидов. Все поголовно отвечают про копирование и про то что стурктуры в стеке, а классы в хипе(то что в интеренете за 5 минут можно найти). Следущий вопрос сразу а что будет если структура является полем класса, и тут труба... для тех кто ответит следующий вопрос: а зачем вообще структуры в C# и в чем разница массива структур и массива классов(например точка X,Y). А понимание ответов на самом деле очень важно при работе с большими данными. 2. Попросить рассписать сингелтон - таже беда, все слышали, но никто толком написать не может 3. В старом шарпе интерфейсу через экстеншены тоже можно методов написать, поэтому ничего кроме синтаксиса сильно не изменилось. 4. Еще 50% джунов и 25% мидов заявляют что Dispose удаляет объекты из памяти сразу по вызову ).
1. когда поле класса я не спрашиваю, мне главное, чтобы понимали, что будет с боксингом 2. о да, я тоже часто вижу, что народ не понимает, как реально реализовать защиту от прямого создания объекта 4. есть такое. в Канаде вижу, что больше 50% не понимает, что вообще значит managed фреймворк и не понимает, зачем нужно Dispose, если. ресурсы очищает коллектор и часто дают версию, что это для очистки памяти без GC
Какие-то легкие вопросы. В СНГ сейчас ко всему перечисленному спрашивают (на Senior позиции): - Детали работы сборщика мусора, поколения объектов - Task'и и детали работы: что там с потоками, перехват исключений, в каком потоке продолжается выполнение после await - IEnumerable vs IQueryable - Рефлексия - SOLID, DRY, KISS - Паттерны проектирования (одним синглтоном не отделаться, да и вообще начинать рассказ с синглотона - дурной тон) - Многопоточность: дедлоки, примитивы синхронизации (lock, semaphore, monitor, mutex, event wait handle, Auto/Manual Reset Event и остальные) в общем, CLR via C# приходится обновлять перед тем как собеседовать(ся)🤣
походу на junior/middle/senior нынче одинаковые вопросы, у меня на middle спрашивали про неотслеживаемые ошибки на С# ( не OutOfMemory), это был вопрос про AccesViolent и кучу похожих
На сколько я знаю value тайпы далеко не всегда хранятся на стеке. Например, если это поле класса это будет храниться в хипе. С коллекциями так же. Ну и боксинг анбоксинг туда же
Абсолютно верно, я не представляю, как члены класса можно хранить в стеке, они же часть класса и поэтому улетают в кучу вместе с классом. Поэтому в закрепленном комментарии и стоит дисклеймер.
@@Dev-lessons абсолютно согласен. Ещё у нас часто спрашивают про замыкания и всякие ньюансы использования yeild return. И обязательно солид - этот солид уже как Отче Наш. У вас такого в списке основных вопросов нет? И ещё - сколько в среднем идёт обычное интервью? (У нас минут 40-60, наверное)
@@Dev-lessons а так, в целом, вопросы очень сильно пересекаются, не знаю, с чего вы взяли, что у нас они разные)ну по крайней мере из своего опыта и опыта друзей
Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить и научить. Я даже видео на эту тему записал: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
В России бы такие простые вопросы, у нас много вопросов на знание, когда дают какой-то конкретный вопрос, который даже при наличии VS не всегда сразу догадаешься, какой будет результат
Не только в России самодуров полно. Любые вопросы, на которые средний синиор не ответит без подготовки, задавать нельзя. Это простое правило нарушается почти всегда. На западе еще до кучи спрашивают про всякие leadership principles, дают задачки на алгоритмы и пр. Единственно верный способ оценить скиллы кандидата на среднюю программерскую вакансию - это попросить написать что-то и наблюдать как человек это делает.
а вот вам кстати вопрос как синьеру. расскажите почему http client нужно использовать в единственном экземпляре и не использовать using при выполнении частых запросов, несмотря на то, что http client реализует idisposable интерфейс
Ты можешь использовать несколько экземпляров или даже с IDisposible, в зависимости от приложения. Для web с нагрузкой лучше использовать один, чтобы переиспользовать один и тот же socket. Это экономичнее. Если нагрузки нет, то проблем не будет. Если нагрузка есть, то со временем можно схватить ошибку SocketException
Нет ответа, надеюсь ты всё же почувствовал подвох. Я же не просто так сказал, что люблю такое, даже намёк, но почему-то многие намёк читают неверно. Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
1) Dispose необходимо вызывать при использовании неуправляемых ресурсов для высвобождения памяти. 2) Интерфейсы реализуются, а не наследуется(для кого то это придирка, а для кого то понимание что такое интерфейс и для чего он нужен). Т.е. множественного наследования нету. В этом ключе как раз не вижу никаких диссонансов в том что дали возможность реализовывать в интерфейсах некоторые методы.
1. ты можешь сделать это и без Dispose. кстати в видео я это не затронул, но неплохо бы еще знать, почему именно Dispose, а не деструктор 2. Меня много раз поправляли, но TH-cam не позволяет изменять видел, поэтому подробно ответил по этому поводу здесь th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Вопрос по Singleton. Часто к нему относятся негативно, называют анти-паттерном. Такого не встречалось? Самого ни разу не спрашивали про паттерны, но ни раз слышал, что когда просят привести пример, Singleton не очень хороший вариант.
Это паттерн и очень хороший, если его правильно применять. А применять его нужно только там, где действительно нужен объект в единственном экземпляре. Прежде чем делать такой объект нужно думать, а действительно ли он нужен в единственном? Его начали называть анти матерном, потому что некоторые программисты стали делать синглтоны даже там, где не нужно
@@Dev-lessons Действительно ли он нужен в единственном экземпляре, мне кажется, не единственный фактор. Я бы еще отметил удобность тестирования. В случае с Dependency Injection проще подменить обертку над подключением к той же БД или брокеру сообщений, например, тестовым fake-классом с готовыми значениями нежели мокать само подключение. То есть формально у нас синглтона не будет, но фактически будем один и тот же объект кидать между классами, его использующими.
@@igor87z Очень сложно рассуждать в общих чертах, тут нужно говорить на конкретных примерах. В твоем примере я не услышала необходимости. Удобство тоже может быть необходимостью. Но это все в общих словах, по твоему описанию я бы все же не стал делать синглтон
из опыта. 1. главный косяк Singleton - отсутствие понимания, что у сущности есть скрытые зависимости. 2. некоторые сценарии могут требовать нового инстанса, а он у вас один и сделать вы с этим ничего не можете.
Благодарю за видео! Вопрос по поводу sql injection - почему нельзя ограничить доступ средствами базы данных? Приложение подключается к БД определенным пользователем БД, так дать этому пользователю ровно столько прав сколько ему нужно? Выборки только из представлений, правка данных только через ХП.
Ограничить права нужно, но не достаточно. Очень часто пользователю нужна возможность удалять свои комментарии и разрешение на удаление данных может эксплуатироваться SQL инъекцией - хакер сможет удалить абсолютно все. Поэтому лучше все же использовать параметры.
@@Dev-lessons удаление (любую DML операцию) нужно делать ТОЛЬКО через хранимые процедуру. В теле хранимой процедуры делать все необходимые проверки и дополнительные операции (например: определить текущего пользователя). У пользователя БД права на исполнения ХП, прямого доступа к таблице нет.
@@mburov1985 тогда появляется следующая задача - версионирование хранимок и поддержка работы логики в них. Это очень сложно при большом проекте. Лучше все выносить в код
@@nikiv2688 я придерживаюсь позиции, что непосредственную правку данных (insert, update, delete, ...) нужно выносить в хранимки, плюс какие то (не сильно сложные) проверки корректности и целостности данных. Плюс какие то не выборки средней сложности, которые неудобно делать представлением. Сложную логику конечно нужно выносить на сервер приложения. БД отвечает за ХРАНЕНИЕ данных, так вот всё что касается хранения (в первую очередь правки данных) нужно держать в БД. Сложную "математику" конечно на сервер приложений.
Сейчас популярно описать реальную задачу и спросить, как собеседуемый будет ее решать. Интервьер обращает внимание на ход мыслей собеседуемого. Лучше задавать уточняющие вопросы обоим сторонам.
@@Dev-lessons а можно да быть сильным фулстеком? Или тонкости везде знать необязательно, при необходимости можно капнуть? С дотнетом ангуляр идёт в основном?
@@shurale85 Практически нереально. Уже 10+ лет в IT - что на front-end, что на back-end постоянно все обновляется. Нужно знать Angular, React, Blasor, Bootstrap, тестирование js, с другой стороны базы данных sql/nosql, Unit Tests, TDD, BDD, DDD, Entity Framework, WebAPI, MinimalAPI, Microservices, Multi-Threading, Task(async/await, etc.). Соответственно сложнее стать Team Lead. Ты вроде опытный, но и НЕ профессионал в какой-то область. Отдельный front-end'ер или back-end'ер тебя спокойно обойдет по знаниям технически.
@@ilyal5712 я поэтому ушел в мобилку)) у меня нет возможности да и желания все свое время посвещать разработке, в мире много еще других важных и интересных вещей. В мобилке кажется предметная область уже все же. Поглядим
Очень хочу уже пойти на первое собеседование, но я все еще новичок :) совсем вот недавно закончил курс Сакутина по шарпу, сейчас ищу другие источники для получения знаний. Крутой монолог, во многом помог.
Окей, может быть я чего-то не понимаю, поясните плиз:если структура это поле класса, а объект класса лежит в хипе, то какого черта структура лежит только в стеке. Она же будет в хипе. Или где-то ошибка?
на 5:55 как в интерфейсе можно делать реализацию? (В самом интерфейсе вроде нет, при добавлении к классу да) Можно пруфы, ссылки на документацию? Мне все же кажется нельзя
@@vladimirmanzhula2730 Глупые вопросы - это нормально, их нужно спрашивать, чтобы узнавать что-то новое. Хуже, когда грубые вопросы. А в твоем случае нет претензий, хороший вопрос.
В С++ разница между классом и структурой только в том что по умолчанию в структуре поля публичные а в классе приватные...и все. Класc не наследует интерфейс а реализует его...:)
Ну видео про вопросы C#, а не С++, а на счет классы реализуют - я спорить не собираюсь. А кто сказал про классы? В видео же сказано про интерфейсы. Посмотри вот это видео на основном канале, там объясняется более подробно этот момент th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
@@Dev-lessons В видео вы упомянули про множественное наследование в С# объясняя это тем , что есть возможность множественного наследования интерфейса. Но как по мне не совсем корректно говорить об наследовании интерфейса. Класс не наследуется от интерфейса а реализует интерфейс. Также вы упомянули про структуры в старых языках(С++ в том числе) и якобы они содержали только данные... но это не так. В С++ класс от структуры мало чем отличается... И да...я не хочу спорить с вами. Это просто мое мнение про услышанное.
@@olexkov4643 Ты явно не посмотрел то видео из предыдущего моего комментария. Класс наследует ОДИН класс. Интерфейс может наследовать ОДИН И БОЛЕЕ интерфейсов. Класс реализует интерфейс. Чтобы я ещё раз не расписывал посмотри видео. На счёт С++ не спорю, но разве это один старый язык? Есть ещё Паскаль, С…
Это если ты будешь инициализировать что-то через метод или свойство. А если в статичном конструкторе, то не нужно. А так как это синглтон, то статичный конструктор обычно проще.
Ещё один попался. Видео старое и ты думаешь, ты первый, кто решил меня поправить, а я оставил видео с такой грубой ошибкой? Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить. Я даже видео на эту тему записал: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Ну, Михаил, интерфейсы же не наследуют, а реализуют)) вроде как. Про SQL инъекцию - да, лучше юзать параметры, причем на последнем собеседовании узнал что СУБД ещё и кеширует такие запросы, и в след. раз просто подставит другой параметр (например в Where...). Вот оно как, оказывается - мелочь, а столько нюансов. Это ещё молчим про то, что будет конкатенация строк НЕ через StringBuider.
Классы реализуют интересы, но интерфейсы могут наследовать интерфейсы и тут как раз и появляется множественное наследование. Так что интерфейс может наследовать два других, а класс может их реализовывать. На счет кеширования - кешируется план выполнения запроса и это будет экономия на компилировании
Доброго времени суток. Подскажите пожалуйста. Был на собеседовании и мне задали следующий вопрос почему и зачем строки в dotnet иммутабельны. Я знаю что они иммутабельны и что "изменение" строки ведет к созданию новой строки. Но по какой причине строки сделали такими я не смог найти в интернете после собеседования.
Я как-то не сталкивался с прямыми наймами из России или Украины. Там где я работал везде работают только с местными, чтобы не связыватся с налоговыми проблемами
Ты не первый, кто так говорит, я даю ссылку на объяснения и комментарий сразу удаляют. Поэтому другие приходят, не видят мой ответ и тоже пытаются меня поправить. Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Какая-то подмена понятий у наследования. Множественного наследования в C# нет, потому что интерфейсы не наследуются, они реализовываются. Просто в синтаксисе языка C# эти вещи выглядят одинаково, по это делает их по сути одинаковыми вещами.
Никакой подмены понятий, ты просто как и все смотришь только на одну конкретную сторону. А более подробно этот вопрос я объяснил тут th-cam.com/video/4X2xqpp35cQ/w-d-xo.html Вот поэтому я и люблю отвечать, что множественное наследование есть, потому что все упёрлись только в классы
@@Dev-lessonsВнезапно, не ожидал, что кто-то ответит мне под видео 2летней давности =) посмотрел видео, что ты скинул, понял что ты имел ввиду, спасибо за ответ!
сталкивался со всем из перечисленным кроме throw. возможно даже и сталкивался, но было это 1 раз, что я уже и забыл. спрашивали кажется этот вопрос в касперском. di очень нравится использовать, а также обожаю abstract factory и factory method
Нужно было почитать комментарии, конечно же меня уже пытались поправить. Интерфейсы могут наследовать интерфейсы и тут нет ограничения на один интерфейс. Один интерфейс может наследовать два и более других интерфейсов. Я специально намекнул в видео на интерфейсы
@@Dev-lessons в таком случае класс реализует все интерфейсы, со всей цепочки наследования. Это уже уклон в философию) В доке написано что это множественная реализация, не наследование
В видео был намек на интерфейсы, но ты не первый, кто сммотрит на них только со стороны классов и реализации. Ты аюсолюьно здесь прав. Но интерфейсы могут наследовать интерфейсы и тут ограничений на количество нет. Именно на наследование интерфейсов был намек.
@@Dev-lessons вопрос не в намёках дружище, а в именовании. Реализация и наследование - это не одно и тоже. И интерфейсы не наследуются а ИМЕННО реализуются, потому что интерфейсы не имеют полей. Например, берём абстрактный класс, где не реализовано ничего, и интерфейс. Оба имеют n-ое количество методов с одинаковыми названиями и сигнатурой. Почему нельзя например НАСЛЕДОВАТЬ два таких абстрактных класса, НО можно РЕАЛИЗОВАТЬ множество таких интерфейсов. Собака зарыта именно в семантическом понимании этих двух процессов, чтобы облегчить проектирование. Интерфейсы задают исключительно поведенческий характер, не хранят свойств, следовательно процесс РЕАЛИЗАЦИИ говорит о некоем наследовании поведения, т.е способах реализации определённых в интерфейсах правил. Процесс наследования предполагает что вместе с поведением к потомку переходит так-же и данные, те поля и константы наследуемого объекта. Эти термины, казалось бы очень очень близки, но семантически они предполагаются как разные. Единственная цель - разделение состояния и поведения, именно с этой целью были введены абстрактные классы, которые способны проявлять себя как сущности способные как хранить некоторые начальные данные об объектах реальности, так и задавать поведение, реализуемое в будущем, благодаря абстрактным членам.
@@DruidMoonkin1 Забудь про классы. Вообще их нет в нашем уравнении. Берем два интерфейса, создаем третий интерфейс и этот интерфейс наследует два других. именно наследует. Это прописано даже в MSDN: docs.microsoft.com/en-us/dotnet/csharp/fundamentals/types/interfaces Interfaces can inherit from one or more interfaces. The derived interface inherits the members from its base interfaces. И так далее
Хорошее, насыщенное видео. Лайк. Только у нас в России за ответы типа есть "наследование интерфейса" интервьюеры обычно делают facepalm и говорят что-то "дорогой соискатель, интерфейсы не наследуют, интерфейсы реализуют".
Ты продолжаешь думать классами, забудь про них и тогда ты поймёшь, о чем я. Интерфейс может наследовать один или более интерфейсов. Это множественное наследование интерфейсов.
Добрый вечер! Очень интересный ролик, после него появился вопрос (и предложение Вам одновременно): не хотели бы Вы сделать видео с типичными джуновскими задачами и их решениями? вопросы, разобранные в видео, в основном для джунов (как я понял), но владея такими знаниями, кажется, будто ты все равно бесполезен для бизнеса и на работу тебя не возьмут
В Канаде в реальности нет такого явного деления в задачах для начинающего и синьора. Даже начинающих нагружают достаточно хорошо, об этом я говорил на основном канале здесь th-cam.com/video/dkUK5PA2avI/w-d-xo.html
Блин автор, как можно было сказать что делегат это указатель на функцию. Если придираться то делегат это вообще говоря тип данных, но даже если посмотреть на объект типа делегат, то это вообще ну никак не указатель на функцию
Открываем MSDN и читаем: Delegates are similar to C++ function pointers, but delegates are fully object-oriented, and unlike C++ pointers to member functions, delegates encapsulate both an object instance and a method. Перевести что тут написано?
@@Dev-lessons delegate это тип, такой же как string к примеру. Поэтому есть объект этого типа. Внутри этого объекта есть метод Invoke(), который будет по сигнатуре такой же как и тот метод который мы положим в делегат. Кроме метода инвоук в делегате есть ещё куча всего, объект типа делегат хранится в куче и так далее. В то время как указатель на функции это в первую очередь указатель С++, который содержит информацию об области памяти и ничего более. Никаких объектов и прочее. Теперь вопрос: и где тут тоже самое?
Ты не первый, кто пытается меня поправить. Можно было комментарии посмотреть или вот в этом видео подробно на эту тему сказал th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Всем привет. Пайтон и питон одно и тоже . Нужно все тексты (коды и тд ....) всех языков программирования переделать под пайтон. Языков программирования очень много и многие эти языки не понимают друг друга. Это полный пиз дец. Нужно обучать всех новичков в питон языку. Зачем создавать новые языки? Зачем усложнять себе жизнь? Нужно следующее обновление Пайтона чтобы он понимал другие языки программирования. Чем меньше языков программирования тем проще, удобнее и приятнее писать коды и читать их. Всем нужно начать изучать лишь 1 язык программирования. Да это будет неудобно, сложно и тяжело но оно того стоит. Нужно сам пайтон писать на языке пайтон. Нужно Пайтон улучшать чтобы он мог выполнять все то что умеет делать другие языки. Хватит быть крабом ведре. Отпустите других крабов. 1 и тоже можно делать на разных языках так зачем изучать другие языки? Проще от них отказаться. Это как отказаться от разных видов разъёмов для 1 вида разъёма. И имя ему тайпси. Люди до сих пор используют мини юсб, микро юсб, лайтнинг, тонкая нокия, толстая нокия, микро HDML ..... Все люди перешли на тайпси провод и разъём но некоторые все ещё создают лайтнинг ))))))).
даже если человек разделит мое мнение о инкапсуляции, это не говорит, какой он будет потом программист. Поэтому в Канаде больше на практику давят - тестовые задания.
в C# нет множественного наследования! потому что интерфейс не наследуешь а ИМПЛЕМЕНТИРУЕШЬ (реализовываешь), унаследовать можно только поведение и свойства! - не вводите людей в заблуждение!
А ты знал, что интерфейс может наследовать другой интерфейс? Как ты думаешь, сколько интерфейсов может наследоваться интерфейсом? А потом класс реализует все унаследование интерфейсы. Так что множественное наследование есть.
@@Dev-lessons Да знал конечно, но это не наследование! если это наследование тогда бы можно было обратиться к базовому методу родителя! есть такая возможность? это сделано для удобства, что бы не писать один и тот же метод в других интерфейсах!
@@aleksandrdevelopment3321 А что это тогда? Согласно MSDN это не удобство, а Interfaces can INHERIT from one or more interfaces, источник здесь docs.microsoft.com/en-us/dotnet/csharp/fundamentals/types/interfaces
@@Dev-lessons это сказано не в контексте ООП, это специфичная особенность самих интерфейсов, и глупо говорить что это множествественое НАСЛЕДОВАНИЕ! это все равно что свеча в церкви и свеча в двигателе, слово одно но разное обозначение и применение!
@@aleksandrdevelopment3321 Я понял уже из предыдущего поста, что это не наследование, тогда что это? Можнго определение? Желательно с источником, который доказывает твою позицию, как я привел ссылку на MSDN,
@@Dev-lessons Речь не про то, что вы должны или нет. А о том что вы не понимаете зачем добавили реализацию по умолчанию в интерфейсах и какую огромную проблемы этим решили. А все это обсуждалось создателями .NET Core. Если коротко, представьте что вы автор Nuget пакета, который использует миллион человек и в какой то момент добавляете в интерфейс новый метод. Что произойдет у тех кто обновит этот пакет?
Структура хранится в стеке, дальше можно не смотреть... Отличие значемого типа от сылочного в том что значимый тип копируется по значению, то есть целеком, и не как не связан со своей копией! А при копировании сылочного типа создаётся новая ссылка на общии данные! А где что хранится вообще не в тему! Горе программист, да и ладно бы с ним, так он людей учит!
Спасибо за отзыв. The first difference between reference types and value types we will consider is that reference types are allocated on the heap and garbage-collected, whereas value types are allocated either on the stack or inline in containing types and deallocated when the stack unwinds or when their containing type gets deallocated. Therefore, allocations and deallocations of value types are in general cheaper than allocations and deallocations of reference types.
Перевести что там написано? Угадаешь, откуда я взял это? MSDN. Пожалуйста, сообщи Microsoft, что у них ошибка в MSDN. Хоть бы подумал, почему по значению работает значимые типы, потому что они не в куче. Они могут там находится, если являются частью класса, тогда они inline in containing types. Но если это просто переменная, то она попадает в стек, где не нужна ссылка, а значит не нужно использовать сборщик мусора, а раз нет ссылки, то сравнение и копирование происходит по значению. docs.microsoft.com/en-us/dotnet/standard/design-guidelines/choosing-between-class-and-struct
абстрактный класс - методы определены но без реализации (с) аутор во-первых, не бывает абстрактных классов бывает тип абстрактного класса - вот это бывает abstract class Base { int Method() { return 0; } // опа! реализация! } и на самом деле я всего лишь про то, что "с точки зрения" некоего языка [что называется общим соглашением] вышеприведённый код является абстрактным классом однако же "с точки зрения" рантайма - всё является типом))) рантайм собсна и проверяет типизацию, и не более того[!], но это же значит, что если сменить тип [и это весьма просто] то рантайм будет считать этот класс вовсе не абстрактным) ну потому что только в типе указана абстрактность, и более нигде впрочем даже если "где то" в потрохах и стоит флаг абстрактного класса, то и этот флаг разумеется можно снять так вы про какие абстрактные классы парите?))) всегда нужно разделять некий язык и реализацию этого языка в суровую реальность рантайма а для рантайма всё то что существует в языке - да плевал рантайм на это всё то, что существует в этом вашем языке ахаха!)))
@@Dev-lessons интересно? т.е. надо полагать что вы даже банальный System.Type ни разу и не курили? слушайте, а вас где и откуда таких берут? банальность object obj = new object(); вы даже не сможете внятно объяснить что это) потому что для вас это всегда _две_ сущности, это ссылка и объект но есть _третья_ сущность - она называется - тип))) object - тип obj - ссылка на объект в куче, на самом деле переменный адрес new object() - объект _типа_ , непосредственно в куче, объект к типу _не_ _привязан_ никак так вот дотнет - это строготипизированный рантайм)))) и только _типами_ всё и определяется в дотнете, потому что хрень сабачья вида "всё является объектом" - не работает а вот заявление "всё является типом" - работает так вот абстрактный класс, а именно его абстрактность - определяется _типом_ , именно в типе записана эта абстрактность))) можете залезть в описатель _типа_ и например отвязаться от одного родителя и привязаться к другому родителю, и всё это описывается в самом _типе_ , но не в объекте и тд и тп
@@Dev-lessons и да, весь этот ваш язык - это абсолютно невменяемая псевдо-философская хрень) потому что компилятор всю вашу псевдо-философскую хрень выкидывает нахрен, и создаёт типы и отношения между ними)))) и всё) вся философия языка испаряется начисто так вот программист - это не тот кто знает какой то там язык программист - это тот кто знает исполняющую среду и как она работает на самом деле
Взято из MSDN: The first difference between reference types and value types we will consider is that reference types are allocated on the heap and garbage-collected, whereas value types are allocated either on the stack or inline in containing types and deallocated when the stack unwinds or when their containing type gets deallocated. Therefore, allocations and deallocations of value types are in general cheaper than allocations and deallocations of reference types.
@@Dev-lessons ты вменяемый? Ты в свободный доступ выкладуешь видео, смотреть и делать выводы может любой, и я тебе еще раз говорюты отвратительный докладчик поработай над собой наберись ума почитай книги, тошо ты чето шаришь в програмировании теюя не делает умным книгу я тебе выше подсказалтс которой начать. Займись чтением а не расказами мне о том что мне не смотреть.
@@Warstarherskiy Можешь делать выводы, не запрещяю. Можешь комментировать, видео открыто. Можешь даже смотреть и дальше, если мазахист. Я разве запрещал? Или ты и читать не умеешь, а только рекомендуешь другим?
Больше видео по подготовке к собеседованиям на моём бусти www.flenov.info/plus/index
СРАЗУ ЗАМЕЧУ - я не давал определений в видео и не пытался дать развернутые ответы. Более подробно по каждому пункту рекомендую еще обратиться к документации. У тех же структур больше отличий и они могут быть не только в стеке, но и в куче (сюрприз), у них есть еще отличие - сравнение по значению... В общем видео не отменяет работы с документацией и книгами
Большое спасибо, за то, что поделились вашим опытом! Позвольте узнать, спрашивают ли на знание структур данных (дек, очередь, кольцевые списки) и как их реализовать на C#?
@@_A-M-A-D-E-U-S_ Ни разу не было такого. В основном практические задачи бывают, для эффективного решения которых нужно понимать разницу в списках и хешах, но это все. В теории не помню, чтобы спросили что такое стек
одно замечание: struct это value type и скорее всего будет храниться в стеке, но runtime себя не ограничивает этим и запросто может его поместить в кучу если посчитает необходимым.
@@vovanchik_ru4208 "посчитает необходимым" - там есть четкие правила, когда в стеке, а когда в куче. Локальная переменная для метода - стек. Переменная класса - куча. Это прописано в MSDN и это очень логично, если понимать, как код выполняется
@@Dev-lessons Но если мы создадим класс, членом которого является структура, то она, как и все остальные данные этого класса окажется в куче.
02:38 Differences in interview questions for C# programmers based on location
05:16 Importance of understanding abstract classes for C# interviews
07:54 Abstract classes vs. Interfaces vs. Structures
10:32 Boxing-unboxing in C# and usage in methods
13:10 Understanding the need for IDisposable in C# programming
15:48 C# programming: Inheritance and Interface
18:26 Importance of design patterns and dependency injection
21:04 Key interview questions for C# developers
Crafted by Merlin AI.
1. Абстрактные классы, классы, интерфейсы и структуры (отличие от класса - Value Type, хранение в стеке. ) данных. Сейчас и record-ы спрашивать начнут.
2. String Builder.
3. IDisposable.
4. Делегаты.
5. Множественное наследование.
6. Object - базовый класс (редко спрашивают)
7. SQL Injection.
8. Throw & Throw Exception (Ex).
9. Singleton (или другие) - как добиться этого.
10. Dependency Injection.
11. Async/await.
Мне кажется этого мало, смотрю hh и там треба намного больше...
@@kashiroko6632на джуна нынче надо все, вообще все по c#, и ещё пару фреймворков, пет проекты и тестовое задание. Тогда есть шансы.
@@TinzZz94Да не, ты чего. Я после универа проходил собес, меня в основном спрашивали про основы языка, базы данных и посмотрели дипломный проект (я писал блог). Минут 20 все длилось и дали оффер по итогу.
@@murr_ka4374 я почему-то не вижу своего комментария (какой-то баг ютуба, что-ли) , но действительно рад, что у тебя все получилось 👍
@@murr_ka4374рад за тебя, меня спрашивали на вакансию тсжаера с зп 30к по асп.нэту, .нэту, тайп скрипту про который ваще нихуя не было, ещё и энтити фрейм прикрутили
Спасибо большое за😊😊😊 информацию очень полезная 😅😊
Как вам новая картинка iPhone 13 в кино режиме?
Спасибо, иниересно. Про наследование от object спрашивают, чтобы потом поговорить какие его методы можно переопределить и как ( ToString, Equals, GetHashCode ). А Singletone при регистрации контекста, например используется.
Михаил, я вас узнал только на третьем ролике.... Хотя книги ваши читал регулярно, да и статейки в хакере :) Спасибо за знания!
Спасибо за отзыв, о книгах я рассказывал на основном канале здесь th-cam.com/video/HRf_DiXZO7o/w-d-xo.html
Спасибо за инфу. Есть о чем подумать, есть что почитать.
Очень приятный монолог)))
Пишу код на Unity, не понял почти ничего, кроме стека и кучи. Значит, я тупой в этом деле, и до Джуна мне как до Китая?))
По сути, почти все, о чем было рассказано в данном видео, задавали мне на собедовании в белорусских IT-компаниях, когда я в 2010 году устраивался на позицию жуионира без опыта работы на коммерческих IT-проектах. У некоторых технических интервьюверов также может встретитьcя фетиш на книги и они спрашивают "а какие книги по программированию вы читаете". Как правило, они любят книги типа C# via CLR или GoF Design Patterns.
Это угар что к джунам в снг такие требования. Я когда проходил тоже с этим столкнулся правда в 2020 году
@@glebfadeev9782 т е Вы считаете, что в России и СНГ к джунам ОЧЕНЬ завышенные требования?
@@evgenyjagushinsky6695 я пытался найти работу на сеньёра этой весной в РФ, вопросы описанные в ролике это детский сад по сравнению с тем что бывает спрашивают
про сборщик мусора довольно долго, года с 2014 до 2021 все спрашивали всё и во всех деталях
в Озоне кроме всех паттернов проектирования с их группировкой по назначению ещё спросили паттерны миграции на микросервисы
(их вакансии правда уже полгода висят незакрытые - может и не хотели на самом деле нанимать)
@@glebfadeev9782 вся проблема в том, что за рубежом есть нормальное образование в сфере программирования. А у нас нормальных вузов всего 3-5(МФТИ, ВШЭ ....)
@@evgenyjagushinsky6695 наверное так и есть, если посмотреть вакансии на том же HH джун по мимо языка должен знать как минимум git и sql, а у некоторых там вообще жара docker, redis, kafka. Такое ощущение, что HR просто пишет весь стек который использует компания, но скорее всего джун этим врятли будет заниматься сразу после оффера.
Абстрактный класс:
1. Нельзя создавать объекты
2. Можно реализовывать свойства и методы
3. Позволяет объединить через наследование похожие по сущности классы
4. Абстрактрый класс именно наследуется, а не реализуется
5. Члены класса не обязательно должны быть public
6. Нет множественного наследования (относится ко всем классам)
Интерфейс:
1. Содержит только объявление методов и свойств без их реализации ( в последних версиях можно реализовывать)
2. Методы и свойства обязательно должны быть public
3. Объединяет разные по сущности классы, имеющие одинаковые свойства и методы, определенные в интерфейсе
4. Именно реализуется, а не наследуется
5. Возможна множественная реализация
Достаточно хороший список из отличий, никто так много не затребует. Я так понимаю, про наследование ты подчеркнул в ответ на мое утверждение про множественное наследование? Оно должно быть в списке интерфейсов. Я сказал, что в С# есть множественное наследование и ничего не говорил про классы, а даже намекнул на интерфейсы. Интерфейсы могут наследовать один и более интерфейсов. А классы уже (как ты правильно сказал) реализуют это.
Аааа увидел, у тебя там ещё один комментарий был и ты его видимо удалил и написал мне свою версию. Интерфейсы содержат только объявления методов, а абстрактные могут содержать объявления, обычно на собеседовании этого достаточно. Ну остальное ты тоже правильно тут написал.
Интерфейсы не наследуются, они реализуются. Разве нет..?
Однажды я сказал, что они наследуются --> меня послали просто на собеседовании.
Смотря как ты это сказал. Я так понимаю, что ты говорил про классы. Посмотри это видео: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Ну а если тебя послали за то, что ты сказал, что интерфейсы наследуються и говорил в этот момент про классы, то подозреваю, что это токсичная компания.
В динамический SQL в хранимых процедурах нельзя встраивать строковые параметры. В PHP класс наследуется через Extends а интерфейсы через Implement.
Соглашусь с автором по поводу опыта прохождения по собеседованиям. Если вас не взяли в одной компании на работе - не стоит особо отчаиваться. Если нужно - просто тупо ходите по собесам. Среди 10 компаний, где вы проходили собеседование, вы, наверняка, получите офер, как минимум, в одной компании.
В России такие вопросы мне задавали, когда я устраивался на джуна. Сейчас проходил на мидла, это было в блоке базовых вопросов, на которые если не отвечаешь на большую часть, то сразу с тобой прощаются. Так что если это реальные вопросы с собеседований в Канаде, то это вдохновляет :).
В Канаде спрашивают базовые вопросы, а потом идет обязательно практика на час. Я про сам процесс интервью говорил здесь th-cam.com/video/cEZyzKFGCfU/w-d-xo.html
@@Dev-lessons спасибо, посмотрю обязательно. У меня были базовые вопросы, потом более глубокие уже на понимание в том числе и самой .NET платформы, потом задачи - передали управление и нужно было исправит ошибки в коде, изменить реализацию или решить грамотно какую-то задачу с точки зрения архитектуры/читаемости/расширяемости прям в открытом проекте собеседующего и показать результат. Благо задачек с ЛитКода не было :).
видео супер
Структуры не всегда хранятся в стеке - если она часть класса - то будет размещена в heap
В Heap как часть объекта. Я для этого прикрепил комментарий
Спасибо за контент, который ты делаешь. Двигать образование - это круто. Хотел бы отметить, что утверждение "все значимые типы хранятся в стеке" верно лишь от части. Корректнее было бы сказать "все значимые типы хранятся там, где применяются", поскольку поле класса, которое является значимым типом хранится в куче, рядом с самим классом. На мой взгляд, это важно понимать, когда речь идет об организации памяти
Я в видео это не сказал, поэтому сразу же прикрепил комментарий с уточнением.
object спрашивают как раз таки в теме Boxing/Unboxing. Когда метод принимает object т.к. этот метод по какой-то причине не делали generic, то скорее всего ожидают передачи reference type и downcast object к нужному типу. Но можно передать и value type. например int и нарваться на Boxing (когда со стека переменная переедет в кучу).
Информация в видео полезная, спасибо! А вот со множественным наследованием немного факапнулся) интерфейсы мы не наследуем а имлементируем, в джаве это явно показали разными операторами extends и implements)
Я джава не знаю, а ты мог бы посмотреть комментарии, меня уже много раз пытались подловить на моей же уловке. Классы реализуют интерфейсы, но я даже намекал на множественное наследование интерфейсами. Интерфейс может наследовать другой интерфейс и тут ограничения на количество нет. Это именно наследование, а не реализация.
Это прописано даже в MSDN:
@t
Interfaces can inherit from one or more interfaces. The derived interface inherits the members from its base interfaces. И так далее
@@Dev-lessons давай начистоту. Ты не разделил понятия «наследование интерфейсов» и «наследование классов» это 2 разных понятия.
Есть несколько вещей:
1. Наследование интерфейсов
2. Наследование классов
3. Реализация интерфейсов
Ни в коем случае нельзя подменять понятие реализации интерфейсов наследованием, грубая ошибка, как по мне.
Наследование интерфейсов - наследование контракта/расширение контракта.
Наследование классов - расширение логики или функциональности классов.
Реализация интерфейса - реализация контрактов.
Был бы ты образован хоть немного, знал бы, что даже в UML диаграммах связи «реализация» и «наследование» имеют разные обозначения, ведь этому учат на первых курсах университета по софтварному инжинирингу. Но не буду тебя осуждать, если ты выбрал путь программиста, а не разработчика.
Ты же пытаешься втюхать нам, что нет разницы между классом и интерфейсом, говоря, что реализация контракта = наследование. Или даже больше, что иерархия наследований = множественное наследование.
А вообще оставайся при своём мнении, ведь ты для себя придумал правду, с которой тебе неплохо живётся.
@@Dev-lessons и на счёт комментарий, которые ты мне советуешь прочитать.
Проблема в том, что ты читаешь свои комментарии изо дня в день не отходя от кассы. Написали, сразу прочитал. Через тебя проходи весь поток информации из комментариев.
Поставь себя на мое место: я смотрю большое количество видео, где под каждым видео написаны тысячи комментариев, чтобы иметь право на своё мнение, я должен прочитать весь поток комментариев, не распределяя нагрузку, как это делаешь ты.
Отсюда приношу свои извинения за то, что я не веду твой образ жизни, читая каждый день твои комментарии, все что я вижу это рекомендации ютуба по твоим комментариям, среди которых я не встретил ни одного комментария с обсуждением этой темы, вот и решил написать.
@@alexpermenev а причём здесь разделение понятий. Я в видео сказал, что в C# есть множественное наследование, но все думают только про классы. Потом я сказал про интерфейсы, но никто не состыковал это и пишут мне про наследование классов. Разделять наследование и реализацию нужно, потому что это разные вещи
Меня как-то на одном собеседовании очень жестко гоняли по книжке Рихтера (CLR via C#). Спрашивали зачем нужна CLR, для чего это всё? Для чего JIT и т.п.?
И прям досконально, около часа.
Не понимаю смысла таких интервью... А потом мне пришел отказ)) ну и ладно
Или другая сторона медали - в собеседовании на миддла спросили про отличие абстр. класса от интерфейса, я рассказал (и не считаю что я не знаю разницы, это джуновский вопрос).
Не знаю, зачем спрашивают Рихтера и CLR. Это полезно знать для себя, но большинство программистов в реальной жизни эту информацию редко использует. Самая важная информация для всех это ссылочные типы против значений.
у некоторых технических интервьверов бывает фетиш на книги по программированию. Пример из жизни: в 2010 году я устраивался в IT-компанию на позицию жуниора без опыта работы в IT. Мне там сперва задавали практически те же вопросы, что прозвучали в данном видео. По некоторым вопросам я плыл. После этих вопросов интервьювер (он же начальник .NET-отдела) поинтересовался какие книги я читаю. Ну я ему на вскидку назвал пару книг, среди которых была знаменитая книга Рихтера. В результате мне сразу же сделали офер на жуниора с зп 500$ с испытательным сроком в один месяц. Аналогичная ситуация была и у других жуниоров, которые устраивались сюда. Пару месяцев спустя в эту же самую компанию устраивался на позицию жуниора парниша с опытом работы в IT в несколько месяцев. Его на собеседовании спрашивали практически все те же самые вопросы. В том числе и про книги. Он же ответил, что вместо книг предпочитает необходимую информацию гуглить в интернете по мере необходимости. Такой ответ не понравился нашему начальнику .NET-отдела. Скрипя сердцем, парнишу все же взяли на работу, но с испыталкой в три месяца и зп 300$ (вместо стандартных 1 месяца и 500$). Мурыжили парня 3 месяца испыталки, которую он прошел и после ему предложили повышение зп до 350$. Но т.к. парень оказался вундеркиндом по программированию, его такой расклад дел не устроил и он устроился в другую IT-компанию, где ему сходу предложили 800$ зп. А спустя пару месяцев он уже там получал 1600$. Год спустя он поменял место работы и там уже имел зп в 2500$. Вывод: фетиш на книги способен не позволить разглядеть талант специалиста.
Проблема знакомая.
Я работаю в новой зеландии 21 год
1. Record ведут себя иначе при сравнении - это важно!
var person1 = new Person("Tom");
var person2 = new Person("Tom");
Console.WriteLine(person1.Equals(person2)); // TRUE!!!!!!
Сравнение идет на основе значений!
Ну да
Это происходит не потому, что объекты record чем-то особенные. Просто в них переопределены методы сравнения и некоторые другие. По сути, это просто удобный синтаксический сахар.
Отличное видео.
Добавлю из своего опыта прохождения собеседований вопросы, которые задавали мне, может кому-то будет полезно:
1) В чём разница между абстрактным классом и интерфейсом, примеры использования.
2) Разница между анонимным типом и кортежем?
3) Разница между finalizer и disposable?
4) Расскажите про принцип работы GC - поколения и графы объектов.
5) В чем разница между throw без параметра и с параметром?
6) В чём основная фишка словаря?
7) В каких случаях уместно использовать монитор, а в каких мьютекс?
8) Сколько способов создания потока существует, и перечислить с примерами реализации.
а на какую должность собеседовались? Пожалуйста, скажите что не на джуна)))
@@stefano_schmidt , на мидла в Епам, Кпмг, Яндекс)
Реализация методов в интерфейсах это боль!
Я не помню, чтобы я где-то в реальной жизни использовал это
@@Dev-lessons Я использовал. Все просто. Некоторые классы которые реализуют интерфейс могут не реализовать один или более методов (свойств), и тогда будет ошибка. Тогда поможет реализация по умолчанию.
@@redfox7193 Если такое случается, значит инерфейс перегружен, и имеет слишком много функционала, который не всем необходим. В таком случае лучше разделить интерфейс на несколько.
Довольно грубо делать контракт, который должен давать гаранитю наличия некоторого поведения, и в итоге не давать реализацию этого поведения.
Это кстати как раз является нарушением одного из принципов SOLID. I - Interface Segregation Principle (принцип разделения интерфейса).
У меня был знакомый, который джунов на собесах сразу тыкал носом в «clr via c#»
Зачем?)
Вы на времени примерно14:30 говорите про искъюлинг джекшен, верно? Не совсем расслышал. Можете написать как правильно звучит? Интересный вопрос наверно, надо бы ознакомиться с ним. Ещё про дипендент сигжекшен, верно услышал, он именно так называется? И почему строку конкатенацией аж ЗАПРЕЩЕНО собирать, если такая возможность в языке предусмотрена? Заранее спасибо!
Вот здесь подробнее:
th-cam.com/video/Vmd7rvCTzbo/w-d-xo.html и ещё тут тут th-cam.com/video/VAMWNjm4DZY/w-d-xo.html
@@Dev-lessons спасибо!
1. Struct vs Class мой любимый вопрос на собеседовании, на нем плывут 70-80% жунов и мидов. Все поголовно отвечают про копирование и про то что стурктуры в стеке, а классы в хипе(то что в интеренете за 5 минут можно найти). Следущий вопрос сразу а что будет если структура является полем класса, и тут труба... для тех кто ответит следующий вопрос: а зачем вообще структуры в C# и в чем разница массива структур и массива классов(например точка X,Y). А понимание ответов на самом деле очень важно при работе с большими данными.
2. Попросить рассписать сингелтон - таже беда, все слышали, но никто толком написать не может
3. В старом шарпе интерфейсу через экстеншены тоже можно методов написать, поэтому ничего кроме синтаксиса сильно не изменилось.
4. Еще 50% джунов и 25% мидов заявляют что Dispose удаляет объекты из памяти сразу по вызову ).
1. когда поле класса я не спрашиваю, мне главное, чтобы понимали, что будет с боксингом
2. о да, я тоже часто вижу, что народ не понимает, как реально реализовать защиту от прямого создания объекта
4. есть такое. в Канаде вижу, что больше 50% не понимает, что вообще значит managed фреймворк и не понимает, зачем нужно Dispose, если. ресурсы очищает коллектор и часто дают версию, что это для очистки памяти без GC
С приходом последних версий C# можно спрашивать что такое ref struct с ref-полями. Вообще никто не ответит :)
@@nv188-x5i... и брать на работу джуна, который только что читал книжку по последней версии C#. Он и заруинит проект :))
Какие-то легкие вопросы. В СНГ сейчас ко всему перечисленному спрашивают (на Senior позиции):
- Детали работы сборщика мусора, поколения объектов
- Task'и и детали работы: что там с потоками, перехват исключений, в каком потоке продолжается выполнение после await
- IEnumerable vs IQueryable
- Рефлексия
- SOLID, DRY, KISS
- Паттерны проектирования (одним синглтоном не отделаться, да и вообще начинать рассказ с синглотона - дурной тон)
- Многопоточность: дедлоки, примитивы синхронизации (lock, semaphore, monitor, mutex, event wait handle, Auto/Manual Reset Event и остальные)
в общем, CLR via C# приходится обновлять перед тем как собеседовать(ся)🤣
походу на junior/middle/senior нынче одинаковые вопросы, у меня на middle спрашивали про неотслеживаемые ошибки на С# ( не OutOfMemory), это был вопрос про AccesViolent и кучу похожих
@@ВадимГильмутдинов-е3ы это называется структурными исключениями.
Для файлов есть using, чтоб руками ничего не вызывать.
По поводу специфики работы GC меня несколько раз спрашивали. Хотя, по сути это никогда не пригодилось
В Канаде? У меня только однажды, когда подавался в команду, которая занималась архитектурой приложения
На сколько я знаю value тайпы далеко не всегда хранятся на стеке. Например, если это поле класса это будет храниться в хипе. С коллекциями так же. Ну и боксинг анбоксинг туда же
Абсолютно верно, я не представляю, как члены класса можно хранить в стеке, они же часть класса и поэтому улетают в кучу вместе с классом. Поэтому в закрепленном комментарии и стоит дисклеймер.
@@Dev-lessons а я не прочёл) просто у нас тут такой вопрос набирает популярность)
@@КириллТимофеев-ш4к Он реально важен для понимания value типов, но с другой стороны, структуры в реальности мало кто использует в работе
@@Dev-lessons абсолютно согласен. Ещё у нас часто спрашивают про замыкания и всякие ньюансы использования yeild return. И обязательно солид - этот солид уже как Отче Наш. У вас такого в списке основных вопросов нет? И ещё - сколько в среднем идёт обычное интервью? (У нас минут 40-60, наверное)
@@Dev-lessons а так, в целом, вопросы очень сильно пересекаются, не знаю, с чего вы взяли, что у нас они разные)ну по крайней мере из своего опыта и опыта друзей
Интерфейс - это контракт. Он не наследуется, а реализуется. Именно поэтому и говорят, что в шарпе множественное наследование отсутствует.
Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить и научить. Я даже видео на эту тему записал: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
@@Dev-lessons Я "учу" вовсе не вас, а тех, кто будет смотреть это видео с целью вынести из него полезную информацию
@@vykotlov Ну я ничего плохого не имел, когда писал свой комментарий.
Если кто-то работает напрямую с потоками ( Threadings) то для них методы (parameterizedThread) ожидают именно object параметры. Тут может пригодиться.
В России бы такие простые вопросы, у нас много вопросов на знание, когда дают какой-то конкретный вопрос, который даже при наличии VS не всегда сразу догадаешься, какой будет результат
Не только в России самодуров полно. Любые вопросы, на которые средний синиор не ответит без подготовки, задавать нельзя. Это простое правило нарушается почти всегда. На западе еще до кучи спрашивают про всякие leadership principles, дают задачки на алгоритмы и пр. Единственно верный способ оценить скиллы кандидата на среднюю программерскую вакансию - это попросить написать что-то и наблюдать как человек это делает.
а вот вам кстати вопрос как синьеру. расскажите почему http client нужно использовать в единственном экземпляре и не использовать using при выполнении частых запросов, несмотря на то, что http client реализует idisposable интерфейс
Ты можешь использовать несколько экземпляров или даже с IDisposible, в зависимости от приложения. Для web с нагрузкой лучше использовать один, чтобы переиспользовать один и тот же socket. Это экономичнее. Если нагрузки нет, то проблем не будет. Если нагрузка есть, то со временем можно схватить ошибку SocketException
@@Dev-lessons окей зачёт) особенно если не гуглили)
@@Hello_there_777 я только год назад сталкивался с той проблемой и смотрел, что там.
Там память течёт
Оч интересное видео, не знал о стрингбилдере:) лайкосик
Отлично, это хорошо, что я смог рассказать что-то новое
@@Dev-lessons кстати обратил внимание, что в России как раз часто валят этот вопрос. В коде тоже встречал беспредел со строками :).
Вывод, в России все умеют рассуждать и по этому спрашивать подобное не имеет смысла.
интерфейсы не наследуются, а реализуются, у интерфейсов же нет реализации
Интерфейсы не могут наследоваться?
Нет ответа, надеюсь ты всё же почувствовал подвох. Я же не просто так сказал, что люблю такое, даже намёк, но почему-то многие намёк читают неверно. Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
1) Dispose необходимо вызывать при использовании неуправляемых ресурсов для высвобождения памяти.
2) Интерфейсы реализуются, а не наследуется(для кого то это придирка, а для кого то понимание что такое интерфейс и для чего он нужен). Т.е. множественного наследования нету. В этом ключе как раз не вижу никаких диссонансов в том что дали возможность реализовывать в интерфейсах некоторые методы.
1. ты можешь сделать это и без Dispose. кстати в видео я это не затронул, но неплохо бы еще знать, почему именно Dispose, а не деструктор
2. Меня много раз поправляли, но TH-cam не позволяет изменять видел, поэтому подробно ответил по этому поводу здесь th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Вопрос по Singleton. Часто к нему относятся негативно, называют анти-паттерном. Такого не встречалось? Самого ни разу не спрашивали про паттерны, но ни раз слышал, что когда просят привести пример, Singleton не очень хороший вариант.
Это паттерн и очень хороший, если его правильно применять. А применять его нужно только там, где действительно нужен объект в единственном экземпляре. Прежде чем делать такой объект нужно думать, а действительно ли он нужен в единственном? Его начали называть анти матерном, потому что некоторые программисты стали делать синглтоны даже там, где не нужно
@@Dev-lessons Действительно ли он нужен в единственном экземпляре, мне кажется, не единственный фактор. Я бы еще отметил удобность тестирования. В случае с Dependency Injection проще подменить обертку над подключением к той же БД или брокеру сообщений, например, тестовым fake-классом с готовыми значениями нежели мокать само подключение. То есть формально у нас синглтона не будет, но фактически будем один и тот же объект кидать между классами, его использующими.
@@igor87z Очень сложно рассуждать в общих чертах, тут нужно говорить на конкретных примерах. В твоем примере я не услышала необходимости. Удобство тоже может быть необходимостью. Но это все в общих словах, по твоему описанию я бы все же не стал делать синглтон
Как минимум потому что он нарушает солидовские принципы
из опыта. 1. главный косяк Singleton - отсутствие понимания, что у сущности есть скрытые зависимости. 2. некоторые сценарии могут требовать нового инстанса, а он у вас один и сделать вы с этим ничего не можете.
Благодарю за видео! Вопрос по поводу sql injection - почему нельзя ограничить доступ средствами базы данных? Приложение подключается к БД определенным пользователем БД, так дать этому пользователю ровно столько прав сколько ему нужно? Выборки только из представлений, правка данных только через ХП.
Ограничить права нужно, но не достаточно. Очень часто пользователю нужна возможность удалять свои комментарии и разрешение на удаление данных может эксплуатироваться SQL инъекцией - хакер сможет удалить абсолютно все. Поэтому лучше все же использовать параметры.
@@Dev-lessons удаление (любую DML операцию) нужно делать ТОЛЬКО через хранимые процедуру. В теле хранимой процедуры делать все необходимые проверки и дополнительные операции (например: определить текущего пользователя). У пользователя БД права на исполнения ХП, прямого доступа к таблице нет.
@@mburov1985 Можно, но зачем это делать, если параметры надежнее? Они и с точки зрения производительности быстрее
@@mburov1985 тогда появляется следующая задача - версионирование хранимок и поддержка работы логики в них. Это очень сложно при большом проекте. Лучше все выносить в код
@@nikiv2688 я придерживаюсь позиции, что непосредственную правку данных (insert, update, delete, ...) нужно выносить в хранимки, плюс какие то (не сильно сложные) проверки корректности и целостности данных. Плюс какие то не выборки средней сложности, которые неудобно делать представлением. Сложную логику конечно нужно выносить на сервер приложения. БД отвечает за ХРАНЕНИЕ данных, так вот всё что касается хранения (в первую очередь правки данных) нужно держать в БД. Сложную "математику" конечно на сервер приложений.
Сейчас популярно описать реальную задачу и спросить, как собеседуемый будет ее решать. Интервьер обращает внимание на ход мыслей собеседуемого. Лучше задавать уточняющие вопросы обоим сторонам.
А разве интерфейсы наследуются? Мы же их имплементируем, разве нет?
Интерфейс может наследовать интерфейс
Очень понравился формат, насыщенно, без воды и спектакля. Спасибо! Скажите, как чисто бекендеры в спросе или нужны фулстеки?
Там где я работаю в основном фулстеки нужны
@@Dev-lessons а можно да быть сильным фулстеком? Или тонкости везде знать необязательно, при необходимости можно капнуть? С дотнетом ангуляр идёт в основном?
@@shurale85 Знать все невозможно, детали можно нагуглить, главное хорошее понимание. В фронтенде чаще вижу Angular или React
@@shurale85
Практически нереально. Уже 10+ лет в IT - что на front-end, что на back-end постоянно все обновляется. Нужно знать Angular, React, Blasor, Bootstrap, тестирование js, с другой стороны базы данных sql/nosql, Unit Tests, TDD, BDD, DDD, Entity Framework, WebAPI, MinimalAPI, Microservices, Multi-Threading, Task(async/await, etc.). Соответственно сложнее стать Team Lead. Ты вроде опытный, но и НЕ профессионал в какой-то область. Отдельный front-end'ер или back-end'ер тебя спокойно обойдет по знаниям технически.
@@ilyal5712 я поэтому ушел в мобилку)) у меня нет возможности да и желания все свое время посвещать разработке, в мире много еще других важных и интересных вещей. В мобилке кажется предметная область уже все же. Поглядим
В С++ классы и стрктуры ничем не отличаются, кроме модификаторов доступа по умолчанию.
Михаил, подскажи пожалуйста видео, где ты про принципы SOLID рассказываешь.
Когда видео плохо смотрят я его удаляю и тут просмотров было мало. Текстовая версия здесь www.flenov.info/story/show/SOLID
@@Dev-lessons хорошее было видео. Жаль.
Очень хочу уже пойти на первое собеседование, но я все еще новичок :) совсем вот недавно закончил курс Сакутина по шарпу, сейчас ищу другие источники для получения знаний. Крутой монолог, во многом помог.
Бесплатник новогодний? Или платный?
@@dimau8896 Учил по бесплатнику, вроде и с ним норм, там, как мне показалось, более чем достаточно для новичка
@@jonro753metanit почитай лучше
ну что, уже работаешь? проходил собес?
Первый!!!!
🤣😂😅👍🔥
Окей, может быть я чего-то не понимаю, поясните плиз:если структура это поле класса, а объект класса лежит в хипе, то какого черта структура лежит только в стеке. Она же будет в хипе. Или где-то ошибка?
Прочитай прикрепленный комментарий
на 5:55 как в интерфейсе можно делать реализацию? (В самом интерфейсе вроде нет, при добавлении к классу да)
Можно пруфы, ссылки на документацию? Мне все же кажется нельзя
Это называется методы по умолчанию docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods
@@Dev-lessons спасибо за информацию!
Простите за глупые вопросы
@@vladimirmanzhula2730 Глупые вопросы - это нормально, их нужно спрашивать, чтобы узнавать что-то новое. Хуже, когда грубые вопросы. А в твоем случае нет претензий, хороший вопрос.
Про делегаты - Func, Action постоянно в вебе присутствуют, а так же лямбды, так что делегаты не покинули нас и в вебе )
Делегаты еще используются, просто не так, как в десктопе, где они были на каждом углу.
В С++ разница между классом и структурой только в том что по умолчанию в структуре поля публичные а в классе приватные...и все.
Класc не наследует интерфейс а реализует его...:)
Ну видео про вопросы C#, а не С++, а на счет классы реализуют - я спорить не собираюсь. А кто сказал про классы? В видео же сказано про интерфейсы. Посмотри вот это видео на основном канале, там объясняется более подробно этот момент th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
@@Dev-lessons
В видео вы упомянули про множественное наследование в С# объясняя это тем , что есть возможность множественного наследования интерфейса. Но как по мне не совсем корректно говорить об наследовании интерфейса.
Класс не наследуется от интерфейса а реализует интерфейс.
Также вы упомянули про структуры в старых языках(С++ в том числе) и якобы они содержали только данные... но это не так. В С++ класс от структуры мало чем отличается...
И да...я не хочу спорить с вами. Это просто мое мнение про услышанное.
@@olexkov4643 Ты явно не посмотрел то видео из предыдущего моего комментария. Класс наследует ОДИН класс. Интерфейс может наследовать ОДИН И БОЛЕЕ интерфейсов. Класс реализует интерфейс. Чтобы я ещё раз не расписывал посмотри видео.
На счёт С++ не спорю, но разве это один старый язык? Есть ещё Паскаль, С…
@@Dev-lessons
Понял...принял.
В синглтоне помимо private ,нужно использовать lock
Это если ты будешь инициализировать что-то через метод или свойство. А если в статичном конструкторе, то не нужно. А так как это синглтон, то статичный конструктор обычно проще.
Блин, а я оказывается почти все знаю))
Интерфейсы не наследуются, они реализуются.
Ещё один попался. Видео старое и ты думаешь, ты первый, кто решил меня поправить, а я оставил видео с такой грубой ошибкой? Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
@@Dev-lessons ошибка допущена. Наказан.
Но в абстрактных классах могут быть и методы с реализацией
Да могут быть.
интерфейсы не наследуют , а реализуют
Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить. Я даже видео на эту тему записал: th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
так у типов значений базовым тоже является object
У всех где-то в предках есть object
@@Dev-lessons в том и прикол что object ссылочный но он все равно предок для типов значений, в этом есть большая тонкость
Ну, Михаил, интерфейсы же не наследуют, а реализуют)) вроде как.
Про SQL инъекцию - да, лучше юзать параметры, причем на последнем собеседовании узнал что СУБД ещё и кеширует такие запросы, и в след. раз просто подставит другой параметр (например в Where...). Вот оно как, оказывается - мелочь, а столько нюансов. Это ещё молчим про то, что будет конкатенация строк НЕ через StringBuider.
Классы реализуют интересы, но интерфейсы могут наследовать интерфейсы и тут как раз и появляется множественное наследование. Так что интерфейс может наследовать два других, а класс может их реализовывать.
На счет кеширования - кешируется план выполнения запроса и это будет экономия на компилировании
Доброго времени суток. Подскажите пожалуйста. Был на собеседовании и мне задали следующий вопрос почему и зачем строки в dotnet иммутабельны. Я знаю что они иммутабельны и что "изменение" строки ведет к созданию новой строки. Но по какой причине строки сделали такими я не смог найти в интернете после собеседования.
безопасность, никогда не будет выхода за пределы памяти выделенной для строки по. записи.
@@Dev-lessons Спасибо.
Скажите, пожалуйста, как в Канаде и Штатах относится к удаленке в общем, и к удаленке с ребятам из России, Украины
Я как-то не сталкивался с прямыми наймами из России или Украины. Там где я работал везде работают только с местными, чтобы не связыватся с налоговыми проблемами
не согласен насчет множественного наследования, т.к. интерфейсы мы именно что имплементируем(реализуем), а не наследуем - термин другой)
Ты не первый, кто так говорит, я даю ссылку на объяснения и комментарий сразу удаляют. Поэтому другие приходят, не видят мой ответ и тоже пытаются меня поправить. Посмотри вот это видео примерно после середины, где-то на 13-й минуте th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
@@Dev-lessons а, ну теперь понятно что имелось ввиду, спасибо)
Какая-то подмена понятий у наследования. Множественного наследования в C# нет, потому что интерфейсы не наследуются, они реализовываются. Просто в синтаксисе языка C# эти вещи выглядят одинаково, по это делает их по сути одинаковыми вещами.
Никакой подмены понятий, ты просто как и все смотришь только на одну конкретную сторону. А более подробно этот вопрос я объяснил тут th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
Вот поэтому я и люблю отвечать, что множественное наследование есть, потому что все упёрлись только в классы
@@Dev-lessonsВнезапно, не ожидал, что кто-то ответит мне под видео 2летней давности =) посмотрел видео, что ты скинул, понял что ты имел ввиду, спасибо за ответ!
@@АлексейПоздеев-п3ю Стараюсь отвечать всем
сталкивался со всем из перечисленным кроме throw. возможно даже и сталкивался, но было это 1 раз, что я уже и забыл. спрашивали кажется этот вопрос в касперском.
di очень нравится использовать,
а также обожаю abstract factory
и factory method
И как ты их используешь, опиши в двух словах.
ValueType - тип, который хранится на стэке, это очень слабое объяснение, которое я не приму на уровне выше джуна
Мультинаследования нет, т.к. мы не наследуем интерфейсы, а реализуем
Нужно было почитать комментарии, конечно же меня уже пытались поправить. Интерфейсы могут наследовать интерфейсы и тут нет ограничения на один интерфейс. Один интерфейс может наследовать два и более других интерфейсов. Я специально намекнул в видео на интерфейсы
13:00
Это древнее видео, но я всё равно отвечу) Реализация множества интерфейсов не является множественным наследованием.
А при чем тут реализация? Забудь про классы. Я говорю про наследование интерфейсов. Интерфейс может наследовать 1 и более других интерфейсов.
@@Dev-lessons в таком случае класс реализует все интерфейсы, со всей цепочки наследования. Это уже уклон в философию) В доке написано что это множественная реализация, не наследование
ещё раз, забудь про классы. Один интерфейс может наследовать два интерфейса? Вот тебе множественное наследование интерфейсами
Поэтому то оно и называется не наследованием а реализацией, даже семантически это всё таки две разные операции, несмотря на однородный синтаксис
В видео был намек на интерфейсы, но ты не первый, кто сммотрит на них только со стороны классов и реализации. Ты аюсолюьно здесь прав.
Но интерфейсы могут наследовать интерфейсы и тут ограничений на количество нет. Именно на наследование интерфейсов был намек.
@@Dev-lessons вопрос не в намёках дружище, а в именовании. Реализация и наследование - это не одно и тоже. И интерфейсы не наследуются а ИМЕННО реализуются, потому что интерфейсы не имеют полей. Например, берём абстрактный класс, где не реализовано ничего, и интерфейс. Оба имеют n-ое количество методов с одинаковыми названиями и сигнатурой. Почему нельзя например НАСЛЕДОВАТЬ два таких абстрактных класса, НО можно РЕАЛИЗОВАТЬ множество таких интерфейсов. Собака зарыта именно в семантическом понимании этих двух процессов, чтобы облегчить проектирование.
Интерфейсы задают исключительно поведенческий характер, не хранят свойств, следовательно процесс РЕАЛИЗАЦИИ говорит о некоем наследовании поведения, т.е способах реализации определённых в интерфейсах правил.
Процесс наследования предполагает что вместе с поведением к потомку переходит так-же и данные, те поля и константы наследуемого объекта. Эти термины, казалось бы очень очень близки, но семантически они предполагаются как разные. Единственная цель - разделение состояния и поведения, именно с этой целью были введены абстрактные классы, которые способны проявлять себя как сущности способные как хранить некоторые начальные данные об объектах реальности, так и задавать поведение, реализуемое в будущем, благодаря абстрактным членам.
@@DruidMoonkin1 Забудь про классы. Вообще их нет в нашем уравнении. Берем два интерфейса, создаем третий интерфейс и этот интерфейс наследует два других. именно наследует. Это прописано даже в MSDN:
docs.microsoft.com/en-us/dotnet/csharp/fundamentals/types/interfaces
Interfaces can inherit from one or more interfaces. The derived interface inherits the members from its base interfaces. И так далее
Хорошее, насыщенное видео. Лайк.
Только у нас в России за ответы типа есть "наследование интерфейса" интервьюеры обычно делают facepalm и говорят что-то "дорогой соискатель, интерфейсы не наследуют, интерфейсы реализуют".
Классы реализуют интерфейсы, это бесспорно. Но интерфейсы могут наследовать другие интерфейсы и вот тут доступно множественное наследование.
Интерфейсы реализуем, поэтому нет множ. Наследования
Ты продолжаешь думать классами, забудь про них и тогда ты поймёшь, о чем я. Интерфейс может наследовать один или более интерфейсов. Это множественное наследование интерфейсов.
Второй! из списка)
Добрый вечер! Очень интересный ролик, после него появился вопрос (и предложение Вам одновременно): не хотели бы Вы сделать видео с типичными джуновскими задачами и их решениями? вопросы, разобранные в видео, в основном для джунов (как я понял), но владея такими знаниями, кажется, будто ты все равно бесполезен для бизнеса и на работу тебя не возьмут
В Канаде в реальности нет такого явного деления в задачах для начинающего и синьора. Даже начинающих нагружают достаточно хорошо, об этом я говорил на основном канале здесь th-cam.com/video/dkUK5PA2avI/w-d-xo.html
@@Dev-lessons спасибо за ответ! пойду смотреть :)
Блин автор, как можно было сказать что делегат это указатель на функцию. Если придираться то делегат это вообще говоря тип данных, но даже если посмотреть на объект типа делегат, то это вообще ну никак не указатель на функцию
Не понял, что значит "объект типа делегат"?
Открываем MSDN и читаем: Delegates are similar to C++ function pointers, but delegates are fully object-oriented, and unlike C++ pointers to member functions, delegates encapsulate both an object instance and a method.
Перевести что тут написано?
@@Dev-lessons delegate это тип, такой же как string к примеру. Поэтому есть объект этого типа. Внутри этого объекта есть метод Invoke(), который будет по сигнатуре такой же как и тот метод который мы положим в делегат. Кроме метода инвоук в делегате есть ещё куча всего, объект типа делегат хранится в куче и так далее. В то время как указатель на функции это в первую очередь указатель С++, который содержит информацию об области памяти и ничего более. Никаких объектов и прочее. Теперь вопрос: и где тут тоже самое?
@@Dev-lessons так тут же прямым текстом сказано что это разные вещи)
@@Dev-lessons оно сделано похоже по синтаксису видимо для удобства, под коробкой это в корне разные вещи
Интерфейсы реализуют а не наследуют
Ты не первый, кто пытается меня поправить. Можно было комментарии посмотреть или вот в этом видео подробно на эту тему сказал th-cam.com/video/4X2xqpp35cQ/w-d-xo.html
да я уже похоже готов пройти собес
Это канадские и американские собесы. А то рванешь в Европе, а там спрашивают вопросы на много сложнее
@@Dev-lessons, там конечно меньше спрашивают! Так как раз до Канады добрался, то значит уже сверхзазум!
Всем привет. Пайтон и питон одно и тоже . Нужно все тексты (коды и тд ....) всех языков программирования переделать под пайтон. Языков программирования очень много и многие эти языки не понимают друг друга. Это полный пиз дец. Нужно обучать всех новичков в питон языку. Зачем создавать новые языки? Зачем усложнять себе жизнь? Нужно следующее обновление Пайтона чтобы он понимал другие языки программирования. Чем меньше языков программирования тем проще, удобнее и приятнее писать коды и читать их. Всем нужно начать изучать лишь 1 язык программирования. Да это будет неудобно, сложно и тяжело но оно того стоит. Нужно сам пайтон писать на языке пайтон. Нужно Пайтон улучшать чтобы он мог выполнять все то что умеет делать другие языки. Хватит быть крабом ведре. Отпустите других крабов. 1 и тоже можно делать на разных языках так зачем изучать другие языки? Проще от них отказаться. Это как отказаться от разных видов разъёмов для 1 вида разъёма. И имя ему тайпси. Люди до сих пор используют мини юсб, микро юсб, лайтнинг, тонкая нокия, толстая нокия, микро HDML ..... Все люди перешли на тайпси провод и разъём но некоторые все ещё создают лайтнинг ))))))).
я в шоке, у нас по ооп гоняют
,еду в канаду))
даже если человек разделит мое мнение о инкапсуляции, это не говорит, какой он будет потом программист. Поэтому в Канаде больше на практику давят - тестовые задания.
Реализации в интерфейсах, лол
прикольный язык)
Есть такое
си шарп еще жив?
Конечно
в C# нет множественного наследования! потому что интерфейс не наследуешь а ИМПЛЕМЕНТИРУЕШЬ (реализовываешь), унаследовать можно только поведение и свойства! - не вводите людей в заблуждение!
А ты знал, что интерфейс может наследовать другой интерфейс? Как ты думаешь, сколько интерфейсов может наследоваться интерфейсом? А потом класс реализует все унаследование интерфейсы. Так что множественное наследование есть.
@@Dev-lessons Да знал конечно, но это не наследование! если это наследование тогда бы можно было обратиться к базовому методу родителя! есть такая возможность? это сделано для удобства, что бы не писать один и тот же метод в других интерфейсах!
@@aleksandrdevelopment3321 А что это тогда? Согласно MSDN это не удобство, а Interfaces can INHERIT from one or more interfaces, источник здесь docs.microsoft.com/en-us/dotnet/csharp/fundamentals/types/interfaces
@@Dev-lessons это сказано не в контексте ООП, это специфичная особенность самих интерфейсов, и глупо говорить что это множествественое НАСЛЕДОВАНИЕ! это все равно что свеча в церкви и свеча в двигателе, слово одно но разное обозначение и применение!
@@aleksandrdevelopment3321 Я понял уже из предыдущего поста, что это не наследование, тогда что это? Можнго определение? Желательно с источником, который доказывает твою позицию, как я привел ссылку на MSDN,
Сразу видно, что человек не участвовал в обсуждении реализаций по умолчанию в интерфейсах.
А где я должен был участвовать? Зачем?
@@Dev-lessons Речь не про то, что вы должны или нет. А о том что вы не понимаете зачем добавили реализацию по умолчанию в интерфейсах и какую огромную проблемы этим решили. А все это обсуждалось создателями .NET Core. Если коротко, представьте что вы автор Nuget пакета, который использует миллион человек и в какой то момент добавляете в интерфейс новый метод. Что произойдет у тех кто обновит этот пакет?
Структура хранится в стеке, дальше можно не смотреть...
Отличие значемого типа от сылочного в том что значимый тип копируется по значению, то есть целеком, и не как не связан со своей копией! А при копировании сылочного типа создаётся новая ссылка на общии данные! А где что хранится вообще не в тему! Горе программист, да и ладно бы с ним, так он людей учит!
Спасибо за отзыв.
The first difference between reference types and value types we will consider is that reference types are allocated on the heap and garbage-collected, whereas value types are allocated either on the stack or inline in containing types and deallocated when the stack unwinds or when their containing type gets deallocated. Therefore, allocations and deallocations of value types are in general cheaper than allocations and deallocations of reference types.
Перевести что там написано? Угадаешь, откуда я взял это? MSDN. Пожалуйста, сообщи Microsoft, что у них ошибка в MSDN. Хоть бы подумал, почему по значению работает значимые типы, потому что они не в куче. Они могут там находится, если являются частью класса, тогда они inline in containing types. Но если это просто переменная, то она попадает в стек, где не нужна ссылка, а значит не нужно использовать сборщик мусора, а раз нет ссылки, то сравнение и копирование происходит по значению.
docs.microsoft.com/en-us/dotnet/standard/design-guidelines/choosing-between-class-and-struct
другалёк, ты там не поумнел за два года? Или по-прежнему уверен, что структура хранится НЕ в стеке?
абстрактный класс - методы определены но без реализации (с) аутор
во-первых, не бывает абстрактных классов
бывает тип абстрактного класса - вот это бывает
abstract class Base
{
int Method() { return 0; } // опа! реализация!
}
и на самом деле я всего лишь про то, что "с точки зрения" некоего языка [что называется общим соглашением] вышеприведённый код является абстрактным классом
однако же "с точки зрения" рантайма - всё является типом))) рантайм собсна и проверяет типизацию, и не более того[!], но это же значит, что если сменить тип [и это весьма просто] то рантайм будет считать этот класс вовсе не абстрактным)
ну потому что только в типе указана абстрактность, и более нигде
впрочем даже если "где то" в потрохах и стоит флаг абстрактного класса, то и этот флаг разумеется можно снять
так вы про какие абстрактные классы парите?))) всегда нужно разделять некий язык и реализацию этого языка в суровую реальность рантайма
а для рантайма всё то что существует в языке - да плевал рантайм на это всё то, что существует в этом вашем языке ахаха!)))
Очень интересно, спасибо
@@Dev-lessons интересно? т.е. надо полагать что вы даже банальный System.Type ни разу и не курили?
слушайте, а вас где и откуда таких берут?
банальность
object obj = new object();
вы даже не сможете внятно объяснить что это)
потому что для вас это всегда _две_ сущности, это ссылка и объект
но есть _третья_ сущность - она называется - тип)))
object - тип
obj - ссылка на объект в куче, на самом деле переменный адрес
new object() - объект _типа_ , непосредственно в куче, объект к типу _не_ _привязан_ никак
так вот дотнет - это строготипизированный рантайм)))) и только _типами_ всё и определяется в дотнете, потому что хрень сабачья вида "всё является объектом" - не работает
а вот заявление "всё является типом" - работает
так вот абстрактный класс, а именно его абстрактность - определяется _типом_ , именно в типе записана эта абстрактность)))
можете залезть в описатель _типа_ и например отвязаться от одного родителя и привязаться к другому родителю, и всё это описывается в самом _типе_ , но не в объекте
и тд и тп
@@Dev-lessons и да, весь этот ваш язык - это абсолютно невменяемая псевдо-философская хрень)
потому что компилятор всю вашу псевдо-философскую хрень выкидывает нахрен, и создаёт типы и отношения между ними))))
и всё) вся философия языка испаряется начисто
так вот программист - это не тот кто знает какой то там язык
программист - это тот кто знает исполняющую среду и как она работает на самом деле
@@AEF23C20 Спасибо
ооо парень)) За все valuetype в стеке прям сразу смотреть дальше не буду)) Проблема современных прогеров - никто не знает ничего про процессор))
Не все, зависит от того, где объявлен тип. Но не хочешь смотреть, не смотри. Причём тут процессор я не понял
Взято из MSDN: The first difference between reference types and value types we will consider is that reference types are allocated on the heap and garbage-collected, whereas value types are allocated either on the stack or inline in containing types and deallocated when the stack unwinds or when their containing type gets deallocated. Therefore, allocations and deallocations of value types are in general cheaper than allocations and deallocations of reference types.
Отвратительный тип
Спасибо
@@Dev-lessons дак ну не получается у тебя приятно выглядеть подавать информацию. Прочти братка "величайший торговец мира" тошо ты по праграмированию чето знаешь тебя умным не делает. Слушать тебя паршиво.
@@Warstarherskiy Не слушай, тебя заставили это делать?
@@Dev-lessons ты вменяемый? Ты в свободный доступ выкладуешь видео, смотреть и делать выводы может любой, и я тебе еще раз говорюты отвратительный докладчик поработай над собой наберись ума почитай книги, тошо ты чето шаришь в програмировании теюя не делает умным книгу я тебе выше подсказалтс которой начать. Займись чтением а не расказами мне о том что мне не смотреть.
@@Warstarherskiy Можешь делать выводы, не запрещяю. Можешь комментировать, видео открыто. Можешь даже смотреть и дальше, если мазахист. Я разве запрещал? Или ты и читать не умеешь, а только рекомендуешь другим?