Большое спасибо, за то, что поделились вашим опытом! Позвольте узнать, спрашивают ли на знание структур данных (дек, очередь, кольцевые списки) и как их реализовать на C#?

@@_A-M-A-D-E-U-S_ Ни разу не было такого. В основном практические задачи бывают, для эффективного решения которых нужно понимать разницу в списках и хешах, но это все. В теории не помню, чтобы спросили что такое стек

одно замечание: struct это value type и скорее всего будет храниться в стеке, но runtime себя не ограничивает этим и запросто может его поместить в кучу если посчитает необходимым.

@@vovanchik_ru4208 "посчитает необходимым" - там есть четкие правила, когда в стеке, а когда в куче. Локальная переменная для метода - стек. Переменная класса - куча. Это прописано в MSDN и это очень логично, если понимать, как код выполняется

@@Dev-lessons Но если мы создадим класс, членом которого является структура, то она, как и все остальные данные этого класса окажется в куче.

Мне кажется этого мало, смотрю hh и там треба намного больше...

​@@kashiroko6632на джуна нынче надо все, вообще все по c#, и ещё пару фреймворков, пет проекты и тестовое задание. Тогда есть шансы.

​@@TinzZz94Да не, ты чего. Я после универа проходил собес, меня в основном спрашивали про основы языка, базы данных и посмотрели дипломный проект (я писал блог). Минут 20 все длилось и дали оффер по итогу.

@@murr_ka4374 я почему-то не вижу своего комментария (какой-то баг ютуба, что-ли) , но действительно рад, что у тебя все получилось 👍

Спасибо за отзыв, о книгах я рассказывал на основном канале здесь ukposts.info/have/v-deo/gIKXk3qgj5CAmKM.html

Я в видео это не сказал, поэтому сразу же прикрепил комментарий с уточнением.

В Канаде спрашивают базовые вопросы, а потом идет обязательно практика на час. Я про сам процесс интервью говорил здесь ukposts.info/have/v-deo/m3WLrbCCfX10x4k.html

@@Dev-lessons спасибо, посмотрю обязательно. У меня были базовые вопросы, потом более глубокие уже на понимание в том числе и самой .NET платформы, потом задачи - передали управление и нужно было исправит ошибки в коде, изменить реализацию или решить грамотно какую-то задачу с точки зрения архитектуры/читаемости/расширяемости прям в открытом проекте собеседующего и показать результат. Благо задачек с ЛитКода не было :).

Я джава не знаю, а ты мог бы посмотреть комментарии, меня уже много раз пытались подловить на моей же уловке. Классы реализуют интерфейсы, но я даже намекал на множественное наследование интерфейсами. Интерфейс может наследовать другой интерфейс и тут ограничения на количество нет. Это именно наследование, а не реализация.

Это прописано даже в 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# есть множественное наследование, но все думают только про классы. Потом я сказал про интерфейсы, но никто не состыковал это и пишут мне про наследование классов. Разделять наследование и реализацию нужно, потому что это разные вещи

И как ты их используешь, опиши в двух словах.

Это угар что к джунам в снг такие требования. Я когда проходил тоже с этим столкнулся правда в 2020 году

@@glebfadeev9782 т е Вы считаете, что в России и СНГ к джунам ОЧЕНЬ завышенные требования?

@@evgenyjagushinsky6695 я пытался найти работу на сеньёра этой весной в РФ, вопросы описанные в ролике это детский сад по сравнению с тем что бывает спрашивают про сборщик мусора довольно долго, года с 2014 до 2021 все спрашивали всё и во всех деталях в Озоне кроме всех паттернов проектирования с их группировкой по назначению ещё спросили паттерны миграции на микросервисы (их вакансии правда уже полгода висят незакрытые - может и не хотели на самом деле нанимать)

@@glebfadeev9782 вся проблема в том, что за рубежом есть нормальное образование в сфере программирования. А у нас нормальных вузов всего 3-5(МФТИ, ВШЭ ....)

Отлично, это хорошо, что я смог рассказать что-то новое

@@Dev-lessons кстати обратил внимание, что в России как раз часто валят этот вопрос. В коде тоже встречал беспредел со строками :).

Не только в России самодуров полно. Любые вопросы, на которые средний синиор не ответит без подготовки, задавать нельзя. Это простое правило нарушается почти всегда. На западе еще до кучи спрашивают про всякие leadership principles, дают задачки на алгоритмы и пр. Единственно верный способ оценить скиллы кандидата на среднюю программерскую вакансию - это попросить написать что-то и наблюдать как человек это делает.

Не знаю, зачем спрашивают Рихтера и CLR. Это полезно знать для себя, но большинство программистов в реальной жизни эту информацию редко использует. Самая важная информация для всех это ссылочные типы против значений.

у некоторых технических интервьверов бывает фетиш на книги по программированию. Пример из жизни: в 2010 году я устраивался в IT-компанию на позицию жуниора без опыта работы в IT. Мне там сперва задавали практически те же вопросы, что прозвучали в данном видео. По некоторым вопросам я плыл. После этих вопросов интервьювер (он же начальник .NET-отдела) поинтересовался какие книги я читаю. Ну я ему на вскидку назвал пару книг, среди которых была знаменитая книга Рихтера. В результате мне сразу же сделали офер на жуниора с зп 500$ с испытательным сроком в один месяц. Аналогичная ситуация была и у других жуниоров, которые устраивались сюда. Пару месяцев спустя в эту же самую компанию устраивался на позицию жуниора парниша с опытом работы в IT в несколько месяцев. Его на собеседовании спрашивали практически все те же самые вопросы. В том числе и про книги. Он же ответил, что вместо книг предпочитает необходимую информацию гуглить в интернете по мере необходимости. Такой ответ не понравился нашему начальнику .NET-отдела. Скрипя сердцем, парнишу все же взяли на работу, но с испыталкой в три месяца и зп 300$ (вместо стандартных 1 месяца и 500$). Мурыжили парня 3 месяца испыталки, которую он прошел и после ему предложили повышение зп до 350$. Но т.к. парень оказался вундеркиндом по программированию, его такой расклад дел не устроил и он устроился в другую IT-компанию, где ему сходу предложили 800$ зп. А спустя пару месяцев он уже там получал 1600$. Год спустя он поменял место работы и там уже имел зп в 2500$. Вывод: фетиш на книги способен не позволить разглядеть талант специалиста.

Там где я работаю в основном фулстеки нужны

@@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 я поэтому ушел в мобилку)) у меня нет возможности да и желания все свое время посвещать разработке, в мире много еще других важных и интересных вещей. В мобилке кажется предметная область уже все же. Поглядим

В Heap как часть объекта. Я для этого прикрепил комментарий

1. когда поле класса я не спрашиваю, мне главное, чтобы понимали, что будет с боксингом 2. о да, я тоже часто вижу, что народ не понимает, как реально реализовать защиту от прямого создания объекта 4. есть такое. в Канаде вижу, что больше 50% не понимает, что вообще значит managed фреймворк и не понимает, зачем нужно Dispose, если. ресурсы очищает коллектор и часто дают версию, что это для очистки памяти без GC

С приходом последних версий C# можно спрашивать что такое ref struct с ref-полями. Вообще никто не ответит :)

@@iamsteroid... и брать на работу джуна, который только что читал книжку по последней версии C#. Он и заруинит проект :))

Я не помню, чтобы я где-то в реальной жизни использовал это

@@Dev-lessons Я использовал. Все просто. Некоторые классы которые реализуют интерфейс могут не реализовать один или более методов (свойств), и тогда будет ошибка. Тогда поможет реализация по умолчанию.

Абсолютно верно, я не представляю, как члены класса можно хранить в стеке, они же часть класса и поэтому улетают в кучу вместе с классом. Поэтому в закрепленном комментарии и стоит дисклеймер.

@@Dev-lessons а я не прочёл) просто у нас тут такой вопрос набирает популярность)

@@user-fp6cr1wi2q Он реально важен для понимания value типов, но с другой стороны, структуры в реальности мало кто использует в работе

@@Dev-lessons абсолютно согласен. Ещё у нас часто спрашивают про замыкания и всякие ньюансы использования yeild return. И обязательно солид - этот солид уже как Отче Наш. У вас такого в списке основных вопросов нет? И ещё - сколько в среднем идёт обычное интервью? (У нас минут 40-60, наверное)

@@Dev-lessons а так, в целом, вопросы очень сильно пересекаются, не знаю, с чего вы взяли, что у нас они разные)ну по крайней мере из своего опыта и опыта друзей

Ты можешь использовать несколько экземпляров или даже с IDisposible, в зависимости от приложения. Для web с нагрузкой лучше использовать один, чтобы переиспользовать один и тот же socket. Это экономичнее. Если нагрузки нет, то проблем не будет. Если нагрузка есть, то со временем можно схватить ошибку SocketException

@@Dev-lessons окей зачёт) особенно если не гуглили)

@@Hello_there_777 я только год назад сталкивался с той проблемой и смотрел, что там.

Там память течёт

походу на junior/middle/senior нынче одинаковые вопросы, у меня на middle спрашивали про неотслеживаемые ошибки на С# ( не OutOfMemory), это был вопрос про AccesViolent и кучу похожих

@@user-ji4uc2ce1s это называется структурными исключениями.

Когда видео плохо смотрят я его удаляю и тут просмотров было мало. Текстовая версия здесь www.flenov.info/story/show/SOLID

@@Dev-lessons хорошее было видео. Жаль.

Это паттерн и очень хороший, если его правильно применять. А применять его нужно только там, где действительно нужен объект в единственном экземпляре. Прежде чем делать такой объект нужно думать, а действительно ли он нужен в единственном? Его начали называть анти матерном, потому что некоторые программисты стали делать синглтоны даже там, где не нужно

@@Dev-lessons Действительно ли он нужен в единственном экземпляре, мне кажется, не единственный фактор. Я бы еще отметил удобность тестирования. В случае с Dependency Injection проще подменить обертку над подключением к той же БД или брокеру сообщений, например, тестовым fake-классом с готовыми значениями нежели мокать само подключение. То есть формально у нас синглтона не будет, но фактически будем один и тот же объект кидать между классами, его использующими.

@@igor87z Очень сложно рассуждать в общих чертах, тут нужно говорить на конкретных примерах. В твоем примере я не услышала необходимости. Удобство тоже может быть необходимостью. Но это все в общих словах, по твоему описанию я бы все же не стал делать синглтон

Как минимум потому что он нарушает солидовские принципы

из опыта. 1. главный косяк Singleton - отсутствие понимания, что у сущности есть скрытые зависимости. 2. некоторые сценарии могут требовать нового инстанса, а он у вас один и сделать вы с этим ничего не можете.

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

@@Dev-lessons удаление (любую DML операцию) нужно делать ТОЛЬКО через хранимые процедуру. В теле хранимой процедуры делать все необходимые проверки и дополнительные операции (например: определить текущего пользователя). У пользователя БД права на исполнения ХП, прямого доступа к таблице нет.

@@user-iw6bb4zm4w Можно, но зачем это делать, если параметры надежнее? Они и с точки зрения производительности быстрее

@@user-iw6bb4zm4w тогда появляется следующая задача - версионирование хранимок и поддержка работы логики в них. Это очень сложно при большом проекте. Лучше все выносить в код

@@nikiv2688 я придерживаюсь позиции, что непосредственную правку данных (insert, update, delete, ...) нужно выносить в хранимки, плюс какие то (не сильно сложные) проверки корректности и целостности данных. Плюс какие то не выборки средней сложности, которые неудобно делать представлением. Сложную логику конечно нужно выносить на сервер приложения. БД отвечает за ХРАНЕНИЕ данных, так вот всё что касается хранения (в первую очередь правки данных) нужно держать в БД. Сложную "математику" конечно на сервер приложений.

Вот здесь подробнее: ukposts.info/have/v-deo/jp2Va6iteoqrw6M.html и ещё тут тут ukposts.info/have/v-deo/jnF-i4ShpGp1u40.html

@@Dev-lessons спасибо!

Делегаты еще используются, просто не так, как в десктопе, где они были на каждом углу.

🤣😂😅👍🔥

Бесплатник новогодний? Или платный?

@@dimau8896 Учил по бесплатнику, вроде и с ним норм, там, как мне показалось, более чем достаточно для новичка

@@jonro753metanit почитай лучше

ну что, уже работаешь? проходил собес?

В Канаде в реальности нет такого явного деления в задачах для начинающего и синьора. Даже начинающих нагружают достаточно хорошо, об этом я говорил на основном канале здесь ukposts.info/have/v-deo/nJuGf2uHeGiS130.html

@@Dev-lessons спасибо за ответ! пойду смотреть :)

В Канаде? У меня только однажды, когда подавался в команду, которая занималась архитектурой приложения

Достаточно хороший список из отличий, никто так много не затребует. Я так понимаю, про наследование ты подчеркнул в ответ на мое утверждение про множественное наследование? Оно должно быть в списке интерфейсов. Я сказал, что в С# есть множественное наследование и ничего не говорил про классы, а даже намекнул на интерфейсы. Интерфейсы могут наследовать один и более интерфейсов. А классы уже (как ты правильно сказал) реализуют это.

Аааа увидел, у тебя там ещё один комментарий был и ты его видимо удалил и написал мне свою версию. Интерфейсы содержат только объявления методов, а абстрактные могут содержать объявления, обычно на собеседовании этого достаточно. Ну остальное ты тоже правильно тут написал.

Классы реализуют интересы, но интерфейсы могут наследовать интерфейсы и тут как раз и появляется множественное наследование. Так что интерфейс может наследовать два других, а класс может их реализовывать. На счет кеширования - кешируется план выполнения запроса и это будет экономия на компилировании

Ну видео про вопросы C#, а не С++, а на счет классы реализуют - я спорить не собираюсь. А кто сказал про классы? В видео же сказано про интерфейсы. Посмотри вот это видео на основном канале, там объясняется более подробно этот момент ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

@@Dev-lessons В видео вы упомянули про множественное наследование в С# объясняя это тем , что есть возможность множественного наследования интерфейса. Но как по мне не совсем корректно говорить об наследовании интерфейса. Класс не наследуется от интерфейса а реализует интерфейс. Также вы упомянули про структуры в старых языках(С++ в том числе) и якобы они содержали только данные... но это не так. В С++ класс от структуры мало чем отличается... И да...я не хочу спорить с вами. Это просто мое мнение про услышанное.

@@olexkov4643 Ты явно не посмотрел то видео из предыдущего моего комментария. Класс наследует ОДИН класс. Интерфейс может наследовать ОДИН И БОЛЕЕ интерфейсов. Класс реализует интерфейс. Чтобы я ещё раз не расписывал посмотри видео. На счёт С++ не спорю, но разве это один старый язык? Есть ещё Паскаль, С…

@@Dev-lessons Понял...принял.

Ну да

Это называется методы по умолчанию docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods

@@Dev-lessons спасибо за информацию! Простите за глупые вопросы

@@vladimirmanzhula2730 Глупые вопросы - это нормально, их нужно спрашивать, чтобы узнавать что-то новое. Хуже, когда грубые вопросы. А в твоем случае нет претензий, хороший вопрос.

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

@@Dev-lessons Спасибо.

Это если ты будешь инициализировать что-то через метод или свойство. А если в статичном конструкторе, то не нужно. А так как это синглтон, то статичный конструктор обычно проще.

Зачем?)

Смотря как ты это сказал. Я так понимаю, что ты говорил про классы. Посмотри это видео: ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html Ну а если тебя послали за то, что ты сказал, что интерфейсы наследуються и говорил в этот момент про классы, то подозреваю, что это токсичная компания.

1. ты можешь сделать это и без Dispose. кстати в видео я это не затронул, но неплохо бы еще знать, почему именно Dispose, а не деструктор 2. Меня много раз поправляли, но UKposts не позволяет изменять видел, поэтому подробно ответил по этому поводу здесь ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

Классы реализуют интерфейсы, это бесспорно. Но интерфейсы могут наследовать другие интерфейсы и вот тут доступно множественное наследование.

Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить и научить. Я даже видео на эту тему записал: ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

@@Dev-lessons Я "учу" вовсе не вас, а тех, кто будет смотреть это видео с целью вынести из него полезную информацию

@@vykotlov Ну я ничего плохого не имел, когда писал свой комментарий.

Да могут быть.

а на какую должность собеседовались? Пожалуйста, скажите что не на джуна)))

@@stefano_schmidt , на мидла в Епам, Кпмг, Яндекс)

Интерфейс может наследовать интерфейс

Мог бы комментарии прочитать, ты же явно не первый, кто пытается меня поправить. Я даже видео на эту тему записал: ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

Я как-то не сталкивался с прямыми наймами из России или Украины. Там где я работал везде работают только с местными, чтобы не связыватся с налоговыми проблемами

Прочитай прикрепленный комментарий

А при чем тут реализация? Забудь про классы. Я говорю про наследование интерфейсов. Интерфейс может наследовать 1 и более других интерфейсов.

@@Dev-lessons в таком случае класс реализует все интерфейсы, со всей цепочки наследования. Это уже уклон в философию) В доке написано что это множественная реализация, не наследование

ещё раз, забудь про классы. Один интерфейс может наследовать два интерфейса? Вот тебе множественное наследование интерфейсами

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

Ты не первый, кто так говорит, я даю ссылку на объяснения и комментарий сразу удаляют. Поэтому другие приходят, не видят мой ответ и тоже пытаются меня поправить. Посмотри вот это видео примерно после середины, где-то на 13-й минуте ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

@@Dev-lessons а, ну теперь понятно что имелось ввиду, спасибо)

У всех где-то в предках есть object

@@Dev-lessons в том и прикол что object ссылочный но он все равно предок для типов значений, в этом есть большая тонкость

В видео был намек на интерфейсы, но ты не первый, кто сммотрит на них только со стороны классов и реализации. Ты аюсолюьно здесь прав. Но интерфейсы могут наследовать интерфейсы и тут ограничений на количество нет. Именно на наследование интерфейсов был намек.

​@@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. И так далее

Интерфейсы не могут наследоваться?

Нет ответа, надеюсь ты всё же почувствовал подвох. Я же не просто так сказал, что люблю такое, даже намёк, но почему-то многие намёк читают неверно. Посмотри вот это видео примерно после середины, где-то на 13-й минуте ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

Есть такое

Ты не первый, кто пытается меня поправить. Можно было комментарии посмотреть или вот в этом видео подробно на эту тему сказал ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html

Ты продолжаешь думать классами, забудь про них и тогда ты поймёшь, о чем я. Интерфейс может наследовать один или более интерфейсов. Это множественное наследование интерфейсов.

Это канадские и американские собесы. А то рванешь в Европе, а там спрашивают вопросы на много сложнее

@@Dev-lessons, там конечно меньше спрашивают! Так как раз до Канады добрался, то значит уже сверхзазум!

Никакой подмены понятий, ты просто как и все смотришь только на одну конкретную сторону. А более подробно этот вопрос я объяснил тут ukposts.info/have/v-deo/bIhjrKenp2lmxIU.html Вот поэтому я и люблю отвечать, что множественное наследование есть, потому что все упёрлись только в классы

@@Dev-lessonsВнезапно, не ожидал, что кто-то ответит мне под видео 2летней давности =) посмотрел видео, что ты скинул, понял что ты имел ввиду, спасибо за ответ!

@@user-ml1qv4gx9r Стараюсь отвечать всем

Не понял, что значит "объект типа делегат"?

Открываем 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 оно сделано похоже по синтаксису видимо для удобства, под коробкой это в корне разные вещи

Нужно было почитать комментарии, конечно же меня уже пытались поправить. Интерфейсы могут наследовать интерфейсы и тут нет ограничения на один интерфейс. Один интерфейс может наследовать два и более других интерфейсов. Я специально намекнул в видео на интерфейсы

Очень интересно, спасибо

​@@Dev-lessons интересно? т.е. надо полагать что вы даже банальный System.Type ни разу и не курили? слушайте, а вас где и откуда таких берут? банальность object obj = new object(); вы даже не сможете внятно объяснить что это) потому что для вас это всегда _две_ сущности, это ссылка и объект но есть _третья_ сущность - она называется - тип))) object - тип obj - ссылка на объект в куче, на самом деле переменный адрес new object() - объект _типа_ , непосредственно в куче, объект к типу _не_ _привязан_ никак так вот дотнет - это строготипизированный рантайм)))) и только _типами_ всё и определяется в дотнете, потому что хрень сабачья вида "всё является объектом" - не работает а вот заявление "всё является типом" - работает так вот абстрактный класс, а именно его абстрактность - определяется _типом_ , именно в типе записана эта абстрактность))) можете залезть в описатель _типа_ и например отвязаться от одного родителя и привязаться к другому родителю, и всё это описывается в самом _типе_ , но не в объекте и тд и тп

@@Dev-lessons и да, весь этот ваш язык - это абсолютно невменяемая псевдо-философская хрень) потому что компилятор всю вашу псевдо-философскую хрень выкидывает нахрен, и создаёт типы и отношения между ними)))) и всё) вся философия языка испаряется начисто так вот программист - это не тот кто знает какой то там язык программист - это тот кто знает исполняющую среду и как она работает на самом деле

@@AEF23C20 Спасибо

Спасибо за отзыв. 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

А где я должен был участвовать? Зачем?

@@Dev-lessons Речь не про то, что вы должны или нет. А о том что вы не понимаете зачем добавили реализацию по умолчанию в интерфейсах и какую огромную проблемы этим решили. А все это обсуждалось создателями .NET Core. Если коротко, представьте что вы автор Nuget пакета, который использует миллион человек и в какой то момент добавляете в интерфейс новый метод. Что произойдет у тех кто обновит этот пакет?

А ты знал, что интерфейс может наследовать другой интерфейс? Как ты думаешь, сколько интерфейсов может наследоваться интерфейсом? А потом класс реализует все унаследование интерфейсы. Так что множественное наследование есть.

@@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,

Не все, зависит от того, где объявлен тип. Но не хочешь смотреть, не смотри. Причём тут процессор я не понял

Взято из 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 Можешь делать выводы, не запрещяю. Можешь комментировать, видео открыто. Можешь даже смотреть и дальше, если мазахист. Я разве запрещал? Или ты и читать не умеешь, а только рекомендуешь другим?