Просто о SOLID (Принципы SOLID)

#YauhenK #webDev #ПростоО #SOLID
Всех приветствую в новом видео касте «Просто о».
Добро пожаловать в пилотный выпуск нового видеокаста, который я назвал «Просто о».
В нём я постараюсь простыми словами объяснять сложные вещи, которые можно встретить в программировании и разработке.
Например, SOLID, CI/CD, Agile, Scrum и Kanban, Mutable и Immutable, Critical Rendering Path, парадигмы ООП и ещё много чего интересного.
И в сегодняшнем выпуске мы поговорим о таком принципе ООП, как SOLID.
✒ Timeline:
✔ 0:00 - Введение
✔ 0:59 - Общение сведения
✔ 2:23 - Принцип единой ответственности
✔ 4:42 - Принцип открытости и закрытости
✔ 7:16 - Принцип подстановки Барбары Лисков
✔ 10:11 - Принцип разделение интерфейсов
✔ 12:12 - Принцип инверсии зависимостей
✒ Полезные ссылки:
✔ Конспект лекции: github.com/YauhenKavalchuk/us...
✒ Полный список готовых и планируемых курсов:
✔ Trello: trello.com/b/R6rD7qq8
✒ Автор курса:
✔ KZbin: / yauhenkavalchuk
✔ Instagram: / yauhenkavalchuk
✔ Twitter: / yauhenkavalchuk
✔ VK: YauhenKavalchuk
✔ LinkedIn: / yauhenkavalchuk
✔ GitHub: github.com/YauhenKavalchuk
✔ VK (Группа): webdevcom
✒ Поддержать развитие канала: github.com/YauhenKavalchuk/yo...

[@alexandrkruglyak]

Принципы SOLID можно изучать вечно и каждый раз познавать что то новое, особенно когда применяешь часто на практике) Спасибо!

[@user-tz8qo8tk8p]

Евгений выражаю вам мою искреннюю благодарность за ваш труд! Как всегда все коротко, информативно, и разложенно по полочкам, лайк без вопросов!

[@pavloskuibida6292]

то чувство когда ты джун, тебе нужно знать все, зашел сюда, поставил лайк и решил, что на собесе скажу просто как это расшифровывается)

[@YauhenKavalchuk]

🤣

[@zakharkulbachenko3433]

Сегодня на собеседовании слил этот вопрос) три тим лида ржали с меня

[@DENDYTWOO]

@@zakharkulbachenko3433 прошел собес?

[@extrageniuz]

@@DENDYTWOO видимо он умер

[@immortal_lnight]

Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно

[@user-qp8bt7gq4b]

Отличное видео. Оно настолько минималистично, насколько это нужно, чтобы быть максимально понятным. Эталон. Спасибо.

[@grommaks]

Тема крутая. Однозначно лукас :) 6:27 стрелочная функция getPrice не возвращает цену (нет return) 10:51 какая цель иметь интерфес с геттерами для все моделей автомобилей. Только недавно на sOlid говорил же что ненадо так делать 10:50 Класс реализует интерфейс. Интерфейс может наследовать другой интерфейс... 12:00 Итого мы получили три независимых класса...хотя цель была разделить интерфейсы.. Условно если у нас есть API ядро, которое ожидало этот класс с тремя методами, то теперь такого больше нет... Результат должен был быть class Foo implements BarInterface, BazInterface, BazzzInterface { ... } При условии что при плохой архитектуре было class Foo implements FooInterface { ... } где FooInterface это сумма методов и свойст из BarInterface, BazInterface, BazzzInterface Все остальное мне понравилось, и примеры интересные

[@YauhenKavalchuk]

Спасибо за детальные объяснения нюансов!

[@12345_qwerty]

А в инверсии зависимостей так ли нужны два класса XmlHttpService и XmlHttpRequestService? Почему не реализовать один класс абстракцию с реализацией всего что нужно?

[@grommaks]

@@12345_qwerty Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо. В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)

[@romanhrechuk7775]

Спасибо за Ваш труд! Жду с нетерпением следующее видео!

[@user-lu8ul6rr9q]

Спасибо коллега, побольше такого контента и если можно расскажи про CI/CD

[@YauhenKavalchuk]

Это следующее видео в этом плейлисте, проверяй!

[@engel8486]

Отличное объяснение, хоть и с нюансами некоторыми) спасибо, жду ещё видео такого формата

[@Demasification]

Спасибо! Может в будущих видео будет время рассказать о low, high level modules. Пока что нет четкого понятия. Супер что будут уроки по TypeScript!

[@YauhenKavalchuk]

Подумаю

[@dmytrolambru2984]

Спасибо большое за видео! Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ... Ждем продолжения серии ! :)

[@Jorjeee]

Супер , я вообще не знал что есть такие понятия. Случайно наткнулся та это видео. Спасибо большое))

[@dizelvinable]

Супер! Много читал/смотрел из разных источников. И мало что понимал. Теперь почти всё понял. Спасибо!)

[@denisdubov]

Спасибо полезно и доступно! 👨‍🎓

[@sea-lucky7143]

Спасибо за видео. Было бы прикольно посмотреть все эти принципы в функциональном программирование)

[@YauhenKavalchuk]

Пожалуйста

[@Elator11777]

Как раз то, что искал - спасибо!

[@crashoverride9681]

Спасибо!

[@dmitryfokin5205]

Принцип инверсии зависимостей - хороший принцип, главное не увлекаться уровнями абстракций.

[@eugeniuszjarocki109]

Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)

[@Rapterlol]

Спасибо! Полезная информация!

[@user-genderZi]

Классно объяснил! Спасибо. Все очень понятно. Зачот!

[@user-uk3mc9vd3w]

огромное спасибо за видео! все по делу, понятно и без воды! очень благодарен!

[@YauhenKavalchuk]

Спасибо за отзыв)

[@Brick87Game87]

Круто, спасибо за видео

[@user-ve5xx8dr5l]

Спасибо за полезное видео. Интересно также увидеть как можно реально применить принципы solid в проекте например на react.

[@user-vk6te2eb4p]

Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках. Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова. Но на реальных проектах в реальном мире, - я вас умоляю.

[@dmitryfokin5205]

Принцип подстановки Барбары Лисков - хороший принцип. На практике, обычно, соблюдается сам собой. В голове держать надо.

[@user-wz1tn7fn4s]

Спасибо, очень круто, думаю на repeat будет долго))) про ооп было бы тоже не плохо в таком формате:) огромное спасибо!

[@user-fv3su4yn3i]

Мужик, очень здорово объяснил. Чудесная подача материала, ты большой молодец, продолжай в том же духе) Успехов!

[@YauhenKavalchuk]

Спасибо большое

[@CrueL54]

Спасибо за видео, отличное объяснение.

[@YauhenKavalchuk]

Пожалуйста)

[@vadimm3077]

Спасибо тебе друже! Очень рад что нашел твой канал хотя не часто захожу сюда и как вижу зря!

[@blagumur.kratos]

Просто и понятно, супер пояснение, спасибо!

[@YauhenKavalchuk]

Пожалуйста)

[@fisherenok]

Как всегда годно)

[@user-jr5hw4gx1y]

Спасибо, очень коротко, доступно и понятно

[@YauhenKavalchuk]

Пожалуйста)

[@Ledrunning]

Классное видео! Спасибо за работу!

[@YauhenKavalchuk]

Пожалуйста

[@dsalodki]

действительно просто, подписчиков мало ещё бы разобрать grasp и gof

[@SlavaCh]

Нормально подписчиков для it канала, очень хороший результат

[@quieteroks]

Все здорово, но принцип Лисков не раскрыт, как и проблема квадрат прямоугольник. В вашем примере проблема осталась.

[@user-vd9eu5vh5f]

Подскажите где посмотреть более корректный пример?

[@MOLOKOKEFIR]

@@user-vd9eu5vh5f если найдешь скинь пожалуйста)

[@artemtereza669]

@@user-vd9eu5vh5f ota-solid.now.sh/

[@artemtereza669]

ota-solid.now.sh/

[@justasid001]

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

[@Cleannetcode]

Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID

[@YauhenKavalchuk]

Спасибо за отзыв)

[@sergeyivanov3351]

"Реально хочу надеяться..." клевый оборот речи

[@YauhenKavalchuk]

🤣

[@alexaxenov974]

Очень качественное обьяснение спасибо огромное !!!)))

[@YauhenKavalchuk]

Пожалуйста!

[@sanyastorm]

Супер Коротко и ясно Спасибо

[@albertrain7093]

Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)

[@dmytrokucheriavyi605]

а еще лучше , если это Typescript, добавить интерфейс/абстактный клас, который будет содержать метод getPrice.

[@Skyfauer]

@@dmytrokucheriavyi605 А этого в этом видео разве не делает автор?

[@alexeybobr4537]

Согласен. Пример с ценами крайне неудачный

[@user-tq9ho2dp5p]

Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.

[@NonAmericanFood]

@@user-tq9ho2dp5p в твоём случае ты о шарпе, так.

[@teamplay5921]

Понравилось, спасибо! Лисков немного подкачал.... палец вверх!

[@eugenekuzmin4825]

Особлива подяка за приклади на TS

[@YauhenKavalchuk]

👍

[@bigdnotation]

Спасибо, всё предельно понятно)

[@YauhenKavalchuk]

Пожалуйста

[@sanzharabdurahmanov5082]

Идеально понятное объяснение принципа SOLID, оргомнейший лайкос !!!

[@YauhenKavalchuk]

Спасибо

[@user-lf7mp6fv1u]

спасибо, то что нужно

[@denisklyachenko292]

Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.

[@awwwesoman]

Спасибо за классный разбор принципов SOLID

[@YauhenKavalchuk]

Спасибо за отзыв

[@user-ee1lx1pe7n]

Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!

[@YauhenKavalchuk]

Пожалуйста. Язык TypeScript - он просто добавляет типизацию

[@MartinEden-ps6ld]

за теслу лайк) А объяснение очень компатное и понятное, спасибо)

[@YauhenKavalchuk]

Спасибо

[@yuriiabramovych1400]

Спасибо, ждем следующий видео))

[@t3m8ch79]

Отличный и понятный ролик

[@zeb2296]

Отлично объяснил. Спасибо!

[@YauhenKavalchuk]

Пожалуйста

[@raul_duken]

Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо

[@YauhenKavalchuk]

Ну по сути можно, но это уже нарушает принцип ООП об абстракции

[@Andrew-strong]

Спасибо! Очень круто! Наберусь наглости и нескромно спрошу: а по SSR (в частности по Next.js) у тебя нет планов на курс?

[@YauhenKavalchuk]

Есть, возможно, даже в этом году появится курс

[@sainco3036]

Спасибо.

[@SochnayaShaurma]

Ничего не понятно, но очень интересно. Видимо я один тут плохо понимаю объяснение. Судя по всему надо ООП в js хорошо знать.

[@denisdubov]

попробуй пару раз пересмотреть, возможно пописать код заодно

[@alexandertarasenko3038]

OOP в JS? :D

[@andriikrashivskiy7140]

в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе

[@user-nc7zt9rj9e]

И все таки спасибо мне как раз для собеседования и нужно было хоть какое то представление иметь))

[@sfiirwuejnn]

В Liskov subtitution подразумевается же, что класс-наследник не должен менять при переопределении поведение метода родительского класса

[@O_Hat]

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

[@YauhenKavalchuk]

Спасибо большое за отзыв

[@user-tg1yr1dt4n]

Готовлюсь к собеседованию и такие видео очень сильно помогают огромное спасибо

[@YauhenKavalchuk]

Пожалуйста

[@ercefwxdx]

Дякую

[@YauhenKavalchuk]

Пожалуйста

[@user-qb5cj6px7q]

Спасибо, интересно послушать о solid с примерами на родном js)

[@YauhenKavalchuk]

Я ж объяснил в самом начале, почему описанные подходы проблематично показывать на JS). Там везде только объекты, максимум класс. Ни абстракций, ни интерфейсов

[@user-qb5cj6px7q]

@@YauhenKavalchuk , имел ввиду typescript, конечно. Спасибо, что поправили

[@user-ei9jd7pw4s]

Спасибо огромное!

[@YauhenKavalchuk]

Пожалуйста

[@user-rg5wh3fx2q]

Спасибо за видио, с меня лайк. Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса

[@dmitry.gashko]

Вы как раз описали почему) Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс

[@evisotskiydev]

Да, принцип подстановки Лисков всё-равно не понял. Но в любом случае, спасибо за старания

[@yaroslavsvitlitskyi1864]

Спасибо за видео

[@YauhenKavalchuk]

Пожалуйста

[@backend1937]

У вас очень крутой канал, спасибо за ваш труд. У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?

[@YauhenKavalchuk]

А зачем вам тогда функция? У вас есть класс, который уже отдаёт цену

[@PC-mv5jj]

👍

[@YauhenKavalchuk]

👍

[@user-kp7mt1qr8r]

10:21 Сущности не должны зависеть от интерфейсов , которые они используют? Или которые не используют? Или которые они не используют?

[@YauhenKavalchuk]

сущности НЕ должны зависеть от интерфейсов, которые НЕ используют

[@Ingvarsson-Ukr]

Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему. А так в целом, хороший видос, много полезного узнал. Спасибо.

[@YauhenKavalchuk]

Пожалуйста

[@Gelen794]

Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков. У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?

[@alex330k47]

Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату

[@YauhenKavalchuk]

¯\_(ツ)_/¯

[@andreygokhan6893]

А в javascript есть что-то похожее на interface и implement или есть какой-то способ их имитации?

[@YauhenKavalchuk]

Нет. В JS это всё классы

[@GreyFoxTube]

Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость

[@andreygokhan6893]

@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...

[@GreyFoxTube]

@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают

[@demidovmaxim1008]

Спасибо

[@temirlanalmassov9408]

Отличное видео, вкратце и понятно, но думаю разрабам с низким уровнем будет сложновато, и возможно стоит посмотреть более подробный разбор принципов

[@YauhenKavalchuk]

👍

[@vskovzgird]

Хорошее объяснение. Не зная тайп скрипт я даже всё понял. Про OCP только поверхностно. Как расширять классы не рассказал

[@vladakymov2123]

Спасибо, Чувак!

[@YauhenKavalchuk]

Пожалуйста

[@vr4836]

Невероятно !! )

[@YauhenKavalchuk]

👍

[@nadianoirnp]

Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )

[@YauhenKavalchuk]

Ну нет интерфейсов, это не проблема. Используйте всё с классами)

[@markostr]

огромное спасибо!

[@YauhenKavalchuk]

Пожалуйста

[@Fioletka_YT]

крутой

[@YauhenKavalchuk]

Спасибо

[@romanbush5164]

Принцыпы сухпайка)

[@YauhenKavalchuk]

?

[@O_Hat]

Принцип подстановки Барбары Лисков. Я бы изобразил абстракцию реализовав в ней метод расчета площади и от неё наследовался бы, реализуя метод установки ширины и высоты. Вопрос. Это же тоже сохраняет принцип подстановки. Нет?

[@YauhenKavalchuk]

Если я правильно понял описание, то нет

[@Max-kr4ie]

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

[@YauhenKavalchuk]

Интерфейсов в JS нету.

[@crashbandi584]

You did a great job 👍

[@YauhenKavalchuk]

Thanks

[@MrSevenZZZ]

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

[@YauhenKavalchuk]

👍

[@kerimamanov7760]

Zdorovo! Tol'ko u menya voprosov stalo bol'she?

[@YauhenKavalchuk]

¯\_(ツ)_/¯

[@StefanTheBlade]

Во втором примере (принцип открытости \ закрытости) с тем же успехом я могу ведь просто не создавать никакой абстракции и все будет отлично работать, у меня тот же самый метод getPrice в каждом объекте. Объясните пожалуйста зачем она (абстракция) нужна? Из другого ролика другого автора по этой же теме, я понял этот принцип так: класс должен быть ОТКРЫТ для расширения и ЗАКРЫТ для изменения (расширяем класс для внедрения нового, продвинутого функционала и при этом не изменяем базовый класс, на котором работает старый функционал. В итоге старый код с большей вероятностью продолжит работать без ошибок). Или я что то не правильно понял смотря это видео, или другой автор просто оказался ближе к истине.

[@YauhenKavalchuk]

Абстракцию можно и не создавать. Всё верно поняли - открыт для расширения, закрыт для изменения. Я ведь тоже делал акцент на этом)

[@leoabalckin8270]

У меня вопрос насчет принципа единственной ответственности (кстати, слова "единый" и "единственный" - паронимы, я бы не стал их взаимозаменять). Итак, "2:20 - итак принцип единой ответственности звучит он как у модуля должна быть только одна причина для изменения или класс должен отвечать только за что-то одно". А вот цитата из Роберта Мартина "Чистая архитектура": "Из всех принципов SOLID наиболее трудно понимаемым является прин цип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соот ветствующего сути. Услышав это название, многие программисты решают: оно означает, или класс должен отвечать только за что-то одно". Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы исполь зуем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID - это не принцип единственной ответственности." Тут возникает сразу несколько вопросов, и самый первый - кому же верить?

[@Scrayerful]

Немного сбивает с толку пример со стоимостями машин: Почему не сделать базовый класс с полем цены, метод getPrice() так же определить в базовом классе, а вариации (Audi, BMW) уже сделать наследниками, в которых переопределяется поле цены ? И второй вариант вообще оставить один класс, а определять самоу стоимость в экземпляре (это вроде как не противоречит смыслу того, что машины стоят по разному) *если что я в js не разбираюсь, но думаю наследование и перегрузка полей там есть ?

[@olegpristashkin9078]

А вот по принципу Single Responsibility, сколько методов может содержать класс?

[@YauhenKavalchuk]

Сколько угодно, ограничений нет. Главное что-бы класться отвечал за что-то одно

[@user-lh4yj4gy7c]

Получается класс Rectangle ( в примере принципа Барбары Лисков ) противоречит принципу единственной ответственности? Ведь у него как минимум 3 метода для изменения

[@YauhenKavalchuk]

И кстати это вполне нормальная ситуация когда сделав код по одному принципу, конфликтуешь с другим. Но в примере противоречия нет - все 3 метода работают с параметрами одной сущности и нет каких-то «левых» манипуляций

[@user-lh4yj4gy7c]

@@YauhenKavalchuk Спасибо за ответ! В этом случае непонятно тогда, в чем принцип единственной ответственности, если суть принципа: "Есть только один повод для изменения". Тогда нужно раскрыть более подробно принцип единственной ответственности. ( это не претензия, я не знаю как правильно, а наоборот пытаюсь понять )

[@andyvoice]

спасибо за видео, но объяснение на тайпскрипт не подходит, например для меня. я понимаю что происходит но не по профилю идёт потеря понимания.

[@YauhenKavalchuk]

Нужны были примеры кода. Я не могу писать одни и те же имплементации на разных языках

[@user-ez2yf3yd3z]

OK!

[@YauhenKavalchuk]

👍

[@yuriiabramovych1400]

Не думали о том, чтобы выпускать курсы на udemy? У вас отлично получается)

[@YauhenKavalchuk]

Нет не думал и не планирую

[@cherimolah9493]

6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута

[@rikkicase]

9:52 в итоге проблема с 9:30 ведь осталась.

[@user-vd9eu5vh5f]

Подскажите где посмотреть более корректный пример?

[@user-iq5gz2rd9w]

@@user-vd9eu5vh5f В wikipedia идеальное описание этого принципа

[@esgaldroeg7820]

Спасибо за видео! Отличное объяснение! но Лисков я чет не понял

[@iharbakhanovich]

Хороший видос

[@JavaScriptcher]

Предлагаю тему к следующему видео: Просто о шаблоне MVC

[@YauhenKavalchuk]

👍 ну да, как вариант

[@user-tc1qq5nm3x]

Музыка на фоне отвлекает. Спасибо за видео

[@YauhenKavalchuk]

Да я понял, в новых выпусках не добавлял