тупые шутки в инете достали, ваши тупые шутки всегда актуальны, спасибо, что параллельно с деградацией позволяете научиться хоть чему-то юным маслятам. этот коммент написан просто чтоб хоть как-то помочь вашему проекту. кто читает это, ставьте лойсы их видосам и комменты пилите. ребята молодцы, поддержим их
"Немного дров и плов готов" эти и подобные фразы отлично разбавляют годную и по делу инфу нотками юмора, что улучшает восприятие и запоминание. Спасибо за такой классный подход к подаче.
Кстати, помимо прочего, интерфейсы могут юзаться для выполнения одних и тех же действий совершенно различными классами. Представим что у нас есть котёнок, гусеница, танк и самолёт. Что у них общего? Они все могут двигаться. Соответсвенно, кроме собственно, возможностей движения у них общего довольно таки мало, так что можно использовать интерфейс IMove. Если всё это реализовывать через абстрактный класс, получится дичайшая помойка.) А уроки очень крутые и сделаны с душой, спасибо.)
а если реализовать через наследование от класса Rocket? порядок вполне сохранится.. Если у прогера в голове помойка то и получится тоже самое и не зависит это от интерфейса. Это имеет смысл если только в классе интерфейсов несколько, а не как у автора в примере один)
@@sergs2919 ну, пример на то и пример. Преимущество интерфейса над абстрактным классом - ты можешь реализовать сколь угодно много интерфейсов. Множественного наследования в C# нет.
@@sergs2919 а если ты хочешь структуру? Структуры могут реализовывать интерфейс, но не могут наследоваться от классов/структур. Впили в ракету движок-структуру - и полетит так же.
Господи, наконец то я понял зачем они нужны. Сколько раз смотрел разные видосы, хрен понятно. Кроме того, что нужно определить функции. Спасибо большое!
Хоть и не без претензий, но это очень хорошо. Одно из лучших среди всех объяснений. Только я бы его перевернул задом наперед, один фиг все важные слова с 7 минуты
Короче, объясняю для тех, кто не понимает (я тоже долго не понимал). Зачем нужны интерфейсы, если можно всё запихнуть в классы? На самом деле интерфейсы позволяют сделать программу гибкой, модульной. Если вы что-то написали, то с помощью интерфейсов вы можете на изичах добавлять/изменять новые фичи, например, вы пишете основную часть программы, ваш друг-программист пишет какую-то подсистему, вы просто пишете интерфейс, он пишет под него свой модуль, который вы подключаете потом на изичах. Потому что программа уже знает, что этот модуль должен делать, вам не нужно вообще ничего переписывать, просто подключить его. Можно вертеть всем как захочется, менять целые куски программы по необходимости, добавлять новые фичи без необходимости переписывать половину кода. Та же самая фишка с совершенно разными объектами, у которых должны быть какие-то общие свойства, но это наследование будет в этом случае извращением, например, они должны обновляться каждый кадр. Незачем пихать сюда целое обычное наследование, можно просто реализовать интерфейс, условно Updateable, и не нужно будет по миллиону раз писать один и тот же код. Так что да, хотите гибкости в разработке, интерфейсы - ваши лучшие друзья.
На фразе "то возможно вам поможет кот" кот реально спрыгнул с подоконника и принялся грызть мою ногу. Типа такой включай комп и запускай студию, харе видосики смотреть
С CryEngine в шепот. Кстати, очень хотелось бы ткнуть носом в то, что в сносках было написано IEngin, но после недавнего стрима в курсе, что эти ошибки специальные. Хитрецы. Лайк
Может я конечно не догоняю, но подскажите пожалуйста. В примере говорится, что без интерфейсов придется постоянно снова реализовывать классы разных ракет. Интерфейсы же помогают стандартизировать все это дело и заменять в одной и той же ракете двигатели. Но как же наследование? Можно же создать класс ракеты, а уже от нее наследовать все другие ракеты. Просто не могу понять, чем тут интерфейс сильно выиграет.
Возможно получится так, что твой дед разберёт эту ракету, достанет из неё двигатель и заведёт от него свой мопед, однако такая реализация у тебя невозможна:( Если же использовать интерфейс, то двигатель будет отдельной сущностью, которую можно запихнуть не только в ракету
А если наследовать разные движки от какого-то базового? Не понимаю в чём прелесть интерфейсов. Если, например, у них есть какой-то метод, который одинаковый для всех движков, то при наследовании можно ничего не трогать, а при реализации интерфейсов придётся копипастить.
@@anxl2191 ну как раз интерфейсы и подразумевают необходимость (ыщыщыщ!) реализации этих методов в каждом конкретном классе-наследнике. И что ещё важно - для интерфейсов разрешено множественное наследование.
Присоединяюсь, хотя данный материал для начинающих, но идея мне нравится. Плюс хотел бы добавить чтобы вы в обучалках учили не использовать "магические цифры" типа 82 или 200. Я думаю Вы понимаете о чем я, что бы ряды говнокодеров пополнялись значительно реже.
я на блупринтах в анриле работаю, там тоже есть так называемый блупринт интерфейс, по сути это метод, который можно вызвать у любого подключенного класса независимо от того, какой это класс. И при вызове не обязательно указывать его. использую для трансляции событий по всем классам сразу, а каждый класс уже что то своё делает.
Спасибо, зачетно! Хотелось бы взглянуть на класс бронетехники в World of Tanks. Вот где раздолье для интерфейсов : движки, орудия, ходовая , экипажи и т.д.
оригинальный подход:) Смотрел с улыбкой. Вобщем очень понравилось и наконец разобрался накой нужны интерфейсы. А еще понравилось возможность сравнить код программ с интерфейсам и без. Кстати о программах (скачал с ГитХаба). У СВОЙСТВ ДВИЖКОВ СЕТТЕРЫ ОТСУТСТВУЮТ!!!. Как итог программы не компилятся.
Очень даже может быть:) стоит 4.5 savepic.ru/14121022.png "error CS0840: InterfacesPart2.YriyLozaEngine.Weight.get должен декларировать тело, так как оно не отмечено как абстрактное или внешнее. Автоматически реализованные свойства должны определять функции доступа get и set."
после рассказов о интерфейсах всегда задаюсь философским вопросом: а что же лучше зафигачить интерфейс или абстрактный класс, от которого будут плодится дочерние
Я тоже когда-то задавался таким вопросом) А разница между ними как разница между солёным и тёплым. Да, абстрактные классы тоже могут скрывать реализацию конкретных наследников и выступать в роли обобщения. Всё потому что они передают наследнику и свой интерфейс (особенности реализации аспектов языка такие). Но их главная задача, всё таки наделять наследников определёнными реализованными членами (чего не могут интерфейсы). При этом всём возможна множественная реализация интерфейсов (чего нельзя делать с абстрактными классами). Если приводить аналогии из реального мира, то абстрактный класс - это что то вроде описания вашего биологического вида. А интерфейсы это ваши жизненные роли, типа: "студент", "сын", "программист" (их может быть бесчисленное количество). В общем на самом деле использовать абстрактный класс вместо интерфейса это как столешницу подпирать ружьём. Да, ружьё может быть неплохой ножкой, но задача у него, всё таки, другая. Кроме того интерфейсы и абстрактные классы можно использовать вместе, да так что каждый будет решать ту задачу, для которой он создан.
Тема не раскрыта. Главного не сказал. А что мешает использования родительский класс Engine от которого наследуются другие движки? По сути разница минимальна. В этом примере действительно есть смысл реализовывать через интерфейс, а не через наследование?
Тут можно же заменить интерфейс IEngine на абстрактный класс? На сколько я всосал эти две темы, то по отношению к данному примеру оно будет аналогичным. Абстрактный класс Engine тоже ведь обобщает все двигатели в себе. И от него может наследоваться класс HatersEngine.
Да, можно, и даже правильней будет, т.к. "двигатель" это абстракция, а остальные конкретные двигатели её реализации. А интерфейсы нужно использовать как "контракт" или "соглашение" о чём-либо, например интерфейс "перемещения в пространстве"(птичка летает, человек идет, червяк ползёт, рыбка плывёт, самолет летит) действия одни и те же, но сущности разные.
Бля, да ты красавчеггг. Решил простую задачу по запуску ракеты расписать на пару сотен строк кода. И при этом втираешь о нужности тут интерфейсов. Госпади, дай этому чуваку реального опыта. А то он походу сам ничего конкретного не программировал никогда. А вместо этого, задачки из учебника решал.
Мощность двигателя, или сила тяги, в ракетных движках измеряется в Ньютонах. Еще в характеристиках есть ISP по нашему удельный импульс, отражает скорость вылетающих из двигателя частиц(продуктов сгорания), по тому как энергия расчитывается как масса умноженная квадрат скорости то все это отражается на эффективность расхода топлива. Т.е. зная ISP можно посчитать сколько топлива в секунду для работы двигателя который обеспечит заданную реактивную тягу. И чем выше значение ISP тем эффективнее двигатель. А зная тягу двигателя и массу ракеты можно вычислить ускорение с которой она может ускоряться, а зная количество топлива можно еще и узнать время работы двигателя и вообще получить максимальную дельту скорости которую может обеспечить данная ракета. Короче программирование это вам не космические корабли запускать!))
Не как не пойму зачем тут интерфейсы если можно было сделать абстрактный класс с разными производными классами двигателей ? Единственное могу предположить если у нас есть несколько типов двигателей ракетные, паровые, ядерные и т.д. То да можно этим двигателям реализовать интерфейс и подставлять любой двигатель. Я так понял предназначение интерфейсов приводить разные объекты к одному типу ?
хуй его знает. в эту тему вникать нужно с головой. так просто в комментах на ютубе готовый ответ никто не даст. а если и даст, то хер поймёшь о чём речь.
Вот вам другой пример, допустим вам нужен ковёр. Есть два способа его получить 1) Обратиться к классу МастерТкач 2) Обратиться к классу АвтоматезированныйТкацкийСтанок. От какого абстрактного класса наследуются эти два конкретных?(теоретически это возможно, но следует взять невероятно высокий уровень абстракции, не имеющий никакого смысла). Но оба этих класса реализуют интерфейс IполучитьКовёр. Абстрактные классы нужны чтобы передать наследникам часть своей структуры, интерфейсы нужны для закрепления одинаковой роли классов в коде, несмотря на абсолютна разные реализации.
@@АлександрКузьмин-ш4ф Блин, вот пример, кроме которого у меня ничего на ум не приходит: есть интерфейс IGetObject, в котором будет метод getObject, который будет возвращать объект с типом object. Потом можно будет получить нужный класс с помощью оператора as. Но разве это все, на что способен интерфейс?
Интерфейсы ещё немного юзабельны в рефлексии, вытянув какой-то тип в виде object, можно привести его к интерфейсному типу и юзать методы, которые определены в этом интерфейсе. (Вместо ебучего dynamic, СУКА С# это строго-типизированый язык) Но надо быть очень аккуратным, тк нужно точно быть уверенным, что мы можем привести тот или инной объект к тому или иному интерфейсу
Я 10 раз пересматривал это видео, а еще другое видео 20 раз, при этом читал книгу Шилдта и практиковал знания в студии и наконец меня озарило нахрена нужны интерфейсы, но я до сих пор не знаю как писать приложения. Читать книгу дальше?
Не понравилось, что а) головная часть может посылать сигналы. выглядит как нарушение принципа единой отвественности б) ссылка на головную част в идеале должна тоже быть интерфейсом. ты тогда всегда сможешь заменить космонавтов, например, на ядерную
Данное видео не обьясняет, что здесь лучше. Обьясняеться то, зачем и как использовать интерфейс, ну или очень похожий по свойствам абстрактный класс. Так что, а рамках этого видео - нет, не логичней . + как мне кажеться, с астрактным классом код тяжелее для понимания
Определённо да. Суть стратегии использовать общий интерфейс алгоритмов, чтобы в дальнейшем свободно заменять один конкретный алгоритм, реализующий интерфейс, на другой в зависимости от контекста
С таким интерфейсом тебе все равно придется клепать классы к каждому двигателю с наследованием от интерфейса.. у тебя в интерфейсе . только получение данных нет передачи в класс.. Какой смысл в такой реализации интерфейса? разве также без интерфейса нельзя наклепать этих классов с наследованием от основного класса Rocket? пример явно не удачен для понимания
Почему вместо архива не расшарить ссылку с кодом, например на гитхабе. Намного же проще было бы исходник просмотреть, + не нужно скачивать/разархивить/запускать студию. А так за видос спасибо, как всегда круто
А почему вместо интерфейса тут нельзя было использовать абстрактный класс? Он в будущем даст больше расширяемости, да и код более логично будет выглядеть.
У меня есть пример использования интерфейса получше: Есть абстрактный класс Car от которого наследуются SimpleCar, SportCar и Truck Так же есть класс Radio и интерфейс IRadio В классе Radio есть методы public void Play() и public void Tune(int times), а в интерфейсе есть методы public RadioPlay() и public RadioTune(int times) Классы SimpleCar и Truck будут реализовывать интерфейс IRadio и иметь в себе поле Radio radio, а реализация будет таковой: public override void RadioPlay() => radio.Play(), соответственным образом будет реализован другой метод Всё, теперь мы можем обобщённо обращаться ко всем объектам, в которых есть радио при помощи интерфейса IRadio
тупые шутки в инете достали, ваши тупые шутки всегда актуальны, спасибо, что параллельно с деградацией позволяете научиться хоть чему-то юным маслятам.
этот коммент написан просто чтоб хоть как-то помочь вашему проекту.
кто читает это, ставьте лойсы их видосам и комменты пилите. ребята молодцы, поддержим их
поддерживаю что молодец.
щас бы самим себе коменты писать под видео
@@Nikodimification лол, я их верный подписчег. И т.к. сам пишу на С# могу их рекомендовать. Можешь думать что хочешь)
Так вот кто северокорейскую ракету кодил..
"Немного дров и плов готов" эти и подобные фразы отлично разбавляют годную и по делу инфу нотками юмора, что улучшает восприятие и запоминание. Спасибо за такой классный подход к подаче.
Чёт не понял, а чё так годно то? где Hello world через интерфейсы
Кстати, помимо прочего, интерфейсы могут юзаться для выполнения одних и тех же действий совершенно различными классами. Представим что у нас есть котёнок, гусеница, танк и самолёт. Что у них общего? Они все могут двигаться. Соответсвенно, кроме собственно, возможностей движения у них общего довольно таки мало, так что можно использовать интерфейс IMove. Если всё это реализовывать через абстрактный класс, получится дичайшая помойка.) А уроки очень крутые и сделаны с душой, спасибо.)
Спасибо, этого объяснения мне не хватало
а если реализовать через наследование от класса Rocket? порядок вполне сохранится.. Если у прогера в голове помойка то и получится тоже самое и не зависит это от интерфейса. Это имеет смысл если только в классе интерфейсов несколько, а не как у автора в примере один)
@@sergs2919 ну, пример на то и пример. Преимущество интерфейса над абстрактным классом - ты можешь реализовать сколь угодно много интерфейсов. Множественного наследования в C# нет.
@@sergs2919 а если ты хочешь структуру? Структуры могут реализовывать интерфейс, но не могут наследоваться от классов/структур. Впили в ракету движок-структуру - и полетит так же.
@@AlexBradley123 множественного наследования классов нет , интерфейсов есть
настолько простого и понятного объяснения интерфейсов я ещё не видел. спасибо, братан, харош)
Господи, наконец то я понял зачем они нужны. Сколько раз смотрел разные видосы, хрен понятно. Кроме того, что нужно определить функции. Спасибо большое!
Хоть и не без претензий, но это очень хорошо. Одно из лучших среди всех объяснений. Только я бы его перевернул задом наперед, один фиг все важные слова с 7 минуты
Смотрю твои видео, и все яснее становится, как надо писать хороший. Спасибо тебе автор за канал и контент крутой!
Короче, объясняю для тех, кто не понимает (я тоже долго не понимал).
Зачем нужны интерфейсы, если можно всё запихнуть в классы?
На самом деле интерфейсы позволяют сделать программу гибкой, модульной. Если вы что-то написали, то с помощью интерфейсов вы можете на изичах добавлять/изменять новые фичи, например, вы пишете основную часть программы, ваш друг-программист пишет какую-то подсистему, вы просто пишете интерфейс, он пишет под него свой модуль, который вы подключаете потом на изичах. Потому что программа уже знает, что этот модуль должен делать, вам не нужно вообще ничего переписывать, просто подключить его.
Можно вертеть всем как захочется, менять целые куски программы по необходимости, добавлять новые фичи без необходимости переписывать половину кода.
Та же самая фишка с совершенно разными объектами, у которых должны быть какие-то общие свойства, но это наследование будет в этом случае извращением, например, они должны обновляться каждый кадр. Незачем пихать сюда целое обычное наследование, можно просто реализовать интерфейс, условно Updateable, и не нужно будет по миллиону раз писать один и тот же код.
Так что да, хотите гибкости в разработке, интерфейсы - ваши лучшие друзья.
Почему бы тогда не использовать Абстрактный класс ?
@@Vov4ik048 в Java например не работает множественное наследование. А интерфейсов можно реализовывать сколько хочешь.
Метод SpecialNasaMethod нам выдал Роскосмос. Ну да ну да
На фразе "то возможно вам поможет кот" кот реально спрыгнул с подоконника и принялся грызть мою ногу. Типа такой включай комп и запускай студию, харе видосики смотреть
Братан хорош!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Спасибо огромное, очень помог!) Всех благ тебе!
Обожаю этот канал, просто обожаю все эти рофлики)))
ахах, почему мне так смешно и мило с этого кота в начале)?
Наконец-то разобрался и активно юзаю, спасибо, уважаемые
С CryEngine в шепот. Кстати, очень хотелось бы ткнуть носом в то, что в сносках было написано IEngin, но после недавнего стрима в курсе, что эти ошибки специальные. Хитрецы. Лайк
Спасибо большое! Очень сильно помог пример с gitHub
Ставь лайк если знал как юзать интерфейсы, но посмотрел чтобы проорать с мемосов
Может я конечно не догоняю, но подскажите пожалуйста. В примере говорится, что без интерфейсов придется постоянно снова реализовывать классы разных ракет. Интерфейсы же помогают стандартизировать все это дело и заменять в одной и той же ракете двигатели. Но как же наследование? Можно же создать класс ракеты, а уже от нее наследовать все другие ракеты. Просто не могу понять, чем тут интерфейс сильно выиграет.
Возможно получится так, что твой дед разберёт эту ракету, достанет из неё двигатель и заведёт от него свой мопед, однако такая реализация у тебя невозможна:(
Если же использовать интерфейс, то двигатель будет отдельной сущностью, которую можно запихнуть не только в ракету
А если наследовать разные движки от какого-то базового? Не понимаю в чём прелесть интерфейсов. Если, например, у них есть какой-то метод, который одинаковый для всех движков, то при наследовании можно ничего не трогать, а при реализации интерфейсов придётся копипастить.
@@anxl2191 ну как раз интерфейсы и подразумевают необходимость (ыщыщыщ!) реализации этих методов в каждом конкретном классе-наследнике.
И что ещё важно - для интерфейсов разрешено множественное наследование.
Когда стрим я со школьных обедов сэкономил буду вам донатить!!
Ориентировачно с лета (но это не точно)
Присоединяюсь, хотя данный материал для начинающих, но идея мне нравится. Плюс хотел бы добавить чтобы вы в обучалках учили не использовать "магические цифры" типа 82 или 200. Я думаю Вы понимаете о чем я, что бы ряды говнокодеров пополнялись значительно реже.
я украл 300 рублей училки в сумке когда стрим буду донатить!
@@AlexM-gn7bp я тебя не совсем понял. В смысле "магические цифры"? Что в них такого?)
Спасибо за уроки :D Только после видосиков начал вкуривать C# Все коротко, понятно и доступно) Жду видео про делегаты с событиями))
вы просто лучшие)
я на блупринтах в анриле работаю, там тоже есть так называемый блупринт интерфейс, по сути это метод, который можно вызвать у любого подключенного класса независимо от того, какой это класс. И при вызове не обязательно указывать его. использую для трансляции событий по всем классам сразу, а каждый класс уже что то своё делает.
Спасибо, зачетно! Хотелось бы взглянуть на класс бронетехники в World of Tanks. Вот где раздолье для интерфейсов : движки, орудия, ходовая , экипажи и т.д.
оригинальный подход:) Смотрел с улыбкой. Вобщем очень понравилось и наконец разобрался накой нужны интерфейсы. А еще понравилось возможность сравнить код программ с интерфейсам и без.
Кстати о программах (скачал с ГитХаба).
У СВОЙСТВ ДВИЖКОВ СЕТТЕРЫ ОТСУТСТВУЮТ!!!. Как итог программы не компилятся.
У вас, походу версия фреймворка не подходящая
savepic.ru/14110779.png
Очень даже может быть:) стоит 4.5
savepic.ru/14121022.png
"error CS0840: InterfacesPart2.YriyLozaEngine.Weight.get должен декларировать тело, так как оно не отмечено как абстрактное или внешнее. Автоматически реализованные свойства должны определять функции доступа get и set."
Из чайников придется переходить во что нибудь другое и висеть ,висеть..
Спасибо, разобралась и поугарала 😅
Не понимал, зачем оно надо, а потом как понял)
после рассказов о интерфейсах всегда задаюсь философским вопросом: а что же лучше зафигачить интерфейс или абстрактный класс, от которого будут плодится дочерние
Я тоже когда-то задавался таким вопросом) А разница между ними как разница между солёным и тёплым.
Да, абстрактные классы тоже могут скрывать реализацию конкретных наследников и выступать в роли обобщения. Всё потому что они передают наследнику и свой интерфейс (особенности реализации аспектов языка такие). Но их главная задача, всё таки наделять наследников определёнными реализованными членами (чего не могут интерфейсы).
При этом всём возможна множественная реализация интерфейсов (чего нельзя делать с абстрактными классами).
Если приводить аналогии из реального мира, то абстрактный класс - это что то вроде описания вашего биологического вида. А интерфейсы это ваши жизненные роли, типа: "студент", "сын", "программист" (их может быть бесчисленное количество).
В общем на самом деле использовать абстрактный класс вместо интерфейса это как столешницу подпирать ружьём. Да, ружьё может быть неплохой ножкой, но задача у него, всё таки, другая. Кроме того интерфейсы и абстрактные классы можно использовать вместе, да так что каждый будет решать ту задачу, для которой он создан.
Все не понимал,нахуя нужны интерфейсы.
Теперь все понял.
Спасибо
Не понял почему Engine нельзя сделать базовым абстрактным классом и наследовать от него новых Engine'ов
Как и всегда ТОП!!
Тема не раскрыта. Главного не сказал. А что мешает использования родительский класс Engine от которого наследуются другие движки? По сути разница минимальна.
В этом примере действительно есть смысл реализовывать через интерфейс, а не через наследование?
оценил отсылку к Аршавину. было очень смешно. спасибо.
Дядьки, сделайте видосик про абстрактные классы, когда нужно использовать их, а когда интерфейс, плз🎎
Реально выручил!!
Тут можно же заменить интерфейс IEngine на абстрактный класс? На сколько я всосал эти две темы, то по отношению к данному примеру оно будет аналогичным. Абстрактный класс Engine тоже ведь обобщает все двигатели в себе. И от него может наследоваться класс HatersEngine.
Да, можно, и даже правильней будет, т.к. "двигатель" это абстракция, а остальные конкретные двигатели её реализации. А интерфейсы нужно использовать как "контракт" или "соглашение" о чём-либо, например интерфейс "перемещения в пространстве"(птичка летает, человек идет, червяк ползёт, рыбка плывёт, самолет летит) действия одни и те же, но сущности разные.
Лучший канал на Ютубе
Все понятно, спасибо огромное) просмотр был очень познавательным, интересным и легким))))
Отлично. Наконец то кто-то адекватно объяснил что такое интерфейс.
Го видос про DI
Озуеные шутки) красава, продолжай, примеры в точку
Все доступно рассказал и доходчиво
годное , понятное видео . СПАСИБО !
Бля, да ты красавчеггг. Решил простую задачу по запуску ракеты расписать на пару сотен строк кода.
И при этом втираешь о нужности тут интерфейсов.
Госпади, дай этому чуваку реального опыта. А то он походу сам ничего конкретного не программировал никогда.
А вместо этого, задачки из учебника решал.
@Eugene Borisik Я приебался к тому, что он сам себе велосипедов нагородил. Сделал два шага путем кувырка назад и приседаний (шоб понятнее было)
Любая вилка может быть движком
главное чтобы она реализовала интерфейс
Мощность двигателя, или сила тяги, в ракетных движках измеряется в Ньютонах. Еще в характеристиках есть ISP по нашему удельный импульс, отражает скорость вылетающих из двигателя частиц(продуктов сгорания), по тому как энергия расчитывается как масса умноженная квадрат скорости то все это отражается на эффективность расхода топлива. Т.е. зная ISP можно посчитать сколько топлива в секунду для работы двигателя который обеспечит заданную реактивную тягу. И чем выше значение ISP тем эффективнее двигатель. А зная тягу двигателя и массу ракеты можно вычислить ускорение с которой она может ускоряться, а зная количество топлива можно еще и узнать время работы двигателя и вообще получить максимальную дельту скорости которую может обеспечить данная ракета. Короче программирование это вам не космические корабли запускать!))
я думал, что это я душный, пока не прочитал этот твой коммент..
Нравятся подача) материал годный, подписался)👍🔥
Очень доступное и понятно видео
Не как не пойму зачем тут интерфейсы если можно было сделать абстрактный класс с разными производными классами двигателей ?
Единственное могу предположить если у нас есть несколько типов двигателей ракетные, паровые, ядерные и т.д. То да можно этим двигателям реализовать интерфейс и подставлять любой двигатель.
Я так понял предназначение интерфейсов приводить разные объекты к одному типу ?
хуй его знает. в эту тему вникать нужно с головой. так просто в комментах на ютубе готовый ответ никто не даст. а если и даст, то хер поймёшь о чём речь.
Я так и не понял, нафига тут интерфейс, если можно вместо него сделать абстрактный класс
Программная сущность в виде гномика
Тогда вопрос: почему бы просто не использовать абстрактные классы?
прост. для иаслят это сложно. и немножк уход в сторону.
Ну блин, я думаю, что я не такой уж новичок, что бы не понять почему абстрактные классы не заменяют интерфейсы. Так что можешь попробывать обьяснить
Вот вам другой пример, допустим вам нужен ковёр. Есть два способа его получить 1) Обратиться к классу МастерТкач 2) Обратиться к классу АвтоматезированныйТкацкийСтанок. От какого абстрактного класса наследуются эти два конкретных?(теоретически это возможно, но следует взять невероятно высокий уровень абстракции, не имеющий никакого смысла). Но оба этих класса реализуют интерфейс IполучитьКовёр. Абстрактные классы нужны чтобы передать наследникам часть своей структуры, интерфейсы нужны для закрепления одинаковой роли классов в коде, несмотря на абсолютна разные реализации.
@@АлександрКузьмин-ш4ф Блин, вот пример, кроме которого у меня ничего на ум не приходит: есть интерфейс IGetObject, в котором будет метод getObject, который будет возвращать объект с типом object. Потом можно будет получить нужный класс с помощью оператора as. Но разве это все, на что способен интерфейс?
Спасибо, прикольна ))
мне понравилось
Интерфейсы ещё немного юзабельны в рефлексии, вытянув какой-то тип в виде object, можно привести его к интерфейсному типу и юзать методы, которые определены в этом интерфейсе. (Вместо ебучего dynamic, СУКА С# это строго-типизированый язык) Но надо быть очень аккуратным, тк нужно точно быть уверенным, что мы можем привести тот или инной объект к тому или иному интерфейсу
Я 10 раз пересматривал это видео, а еще другое видео 20 раз, при этом читал книгу Шилдта и практиковал знания в студии и наконец меня озарило нахрена нужны интерфейсы, но я до сих пор не знаю как писать приложения. Читать книгу дальше?
Чот вспомнился движок CryEngine :D
Почему?
@@TrOll-cr1gf потому что он тоже работает на силе слез фанатов российской сборной
Спасибо большое, было очень понятно!
Афигенно йопта. Лойс.
оу, даже красную плесень вспомнили ...
аххахаха хорош, мне понравилось видео)
Тэк, а теперь говорите мне почему IEngine не мог быть абстрактным классом и так же прекрасно апкаститься?
ой CryEngine, ой ржу не могу)
Двигло с данным типом топлива не то,что до Альфа-центавры долетит,он способен облететь всю вселенную,таща за собой всю планету.
Круто!
Доходчиво и с юмором, давай ещё!👍
Бля чувак єто охуєно. Смотрететь на фоне пока работаєш то что надо
У Вас в скаченном примере кода, лишние записи о Start, Stop, условия для них не выполняются. Ракеты все равно полетят.
Эм. А почему бы просто не сделать тоже самое через классы? Видео не раскрывает сути интерфейсов.
До конца смотри сука
А теперь, например нужно эти ракеты задокументировать в электронном виде. И сериализация в xml с интерфейсами не пашет.. увы(((
Не понравилось, что
а) головная часть может посылать сигналы. выглядит как нарушение принципа единой отвественности
б) ссылка на головную част в идеале должна тоже быть интерфейсом. ты тогда всегда сможешь заменить космонавтов, например, на ядерную
Экстрим код лучше любой водяры!
Большое спасибо! Пока что многое становится понятней ))) может быть и я научусь когда-нибудь программировать, а не тупо писать хранимые процедуры
Мы просто могли создать абстрактный класс и всё
Очень годно!
vpolne krasivo
Го следуъщий видос по абстрактным классам и их отличиям от интерфейсов
Норм. Жду лайк от вас.
Чётко
Не логичней ли в этом примере с ракетами использовать абстрактный класс?
Данное видео не обьясняет, что здесь лучше. Обьясняеться то, зачем и как использовать интерфейс, ну или очень похожий по свойствам абстрактный класс. Так что, а рамках этого видео - нет, не логичней . + как мне кажеться, с астрактным классом код тяжелее для понимания
SpecialNasaMethod, а прислали из Роскосмоса)
Стратегия на практике + property injection))
Немного дров и код готов
Найсович!
Экстрим кот тэвэ!
Айпро, Мистерио поставьте лайк если видите меня
кайф!
Когда осознаешь, что не понимал таких важных вещей - осознаешь так же, какое ты криворукое дно))) Спасибо, видосик зачётный)
можно ли назвать это применением паттерна "стратегия"?
Определённо да. Суть стратегии использовать общий интерфейс алгоритмов, чтобы в дальнейшем свободно заменять один конкретный алгоритм, реализующий интерфейс, на другой в зависимости от контекста
Что за язык, сначала подумал, что c++, после увидел синтаксис c#, это же c# ?
В C++ интерфейсов нет. Есть абстрактные классы.
python
С таким интерфейсом тебе все равно придется клепать классы к каждому двигателю с наследованием от интерфейса.. у тебя в интерфейсе . только получение данных нет передачи в класс.. Какой смысл в такой реализации интерфейса? разве также без интерфейса нельзя наклепать этих классов с наследованием от основного класса Rocket? пример явно не удачен для понимания
😍
Почему ты это не сделал принципом ООП, а то смотрю все в одну строку
Почему вместо архива не расшарить ссылку с кодом, например на гитхабе. Намного же проще было бы исходник просмотреть, + не нужно скачивать/разархивить/запускать студию.
А так за видос спасибо, как всегда круто
Действительно, вы правы. Добавил в описании ссылку на гитхаб.
Благодарю!
А почему вместо интерфейса тут нельзя было использовать абстрактный класс? Он в будущем даст больше расширяемости, да и код более логично будет выглядеть.
У меня есть пример использования интерфейса получше:
Есть абстрактный класс Car от которого наследуются SimpleCar, SportCar и Truck
Так же есть класс Radio и интерфейс IRadio
В классе Radio есть методы public void Play() и public void Tune(int times), а в интерфейсе есть методы public RadioPlay() и public RadioTune(int times)
Классы SimpleCar и Truck будут реализовывать интерфейс IRadio и иметь в себе поле Radio radio, а реализация будет таковой:
public override void RadioPlay() => radio.Play(), соответственным образом будет реализован другой метод
Всё, теперь мы можем обобщённо обращаться ко всем объектам, в которых есть радио при помощи интерфейса IRadio
спасибо!
почему в конце не было фото кота который поможет тем кто не разобрались?
он был в начале?
Кто-нибудь может подсказать какой паттерн тут реализуется ?
Запили движок летающий на моей бездарности кодить, она полетит в самую далекую галактику и может долететь до следующей солнечной системы