Просто о SOLID (Принципы SOLID)
Vložit
- čas přidán 28. 06. 2024
- #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
✒ Автор курса:
✔ CZcams: / yauhenkavalchuk
✔ Instagram: / yauhenkavalchuk
✔ Twitter: / yauhenkavalchuk
✔ VK: YauhenKavalchuk
✔ LinkedIn: / yauhenkavalchuk
✔ GitHub: github.com/YauhenKavalchuk
✔ VK (Группа): webdevcom
✒ Поддержать развитие канала: github.com/YauhenKavalchuk/yo...
Принципы SOLID можно изучать вечно и каждый раз познавать что то новое, особенно когда применяешь часто на практике) Спасибо!
Евгений выражаю вам мою искреннюю благодарность за ваш труд! Как всегда все коротко, информативно, и разложенно по полочкам, лайк без вопросов!
то чувство когда ты джун, тебе нужно знать все, зашел сюда, поставил лайк и решил, что на собесе скажу просто как это расшифровывается)
🤣
Сегодня на собеседовании слил этот вопрос) три тим лида ржали с меня
@@zakharkulbachenko3433 прошел собес?
@@DENDYTWOO видимо он умер
Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно
Отличное видео. Оно настолько минималистично, насколько это нужно, чтобы быть максимально понятным. Эталон. Спасибо.
Спасибо коллега, побольше такого контента и если можно расскажи про CI/CD
Это следующее видео в этом плейлисте, проверяй!
Отличное объяснение, хоть и с нюансами некоторыми) спасибо, жду ещё видео такого формата
Тема крутая. Однозначно лукас :)
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
Все остальное мне понравилось, и примеры интересные
Спасибо за детальные объяснения нюансов!
А в инверсии зависимостей так ли нужны два класса XmlHttpService и XmlHttpRequestService? Почему не реализовать один класс абстракцию с реализацией всего что нужно?
@@12345_qwerty Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо.
В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено
Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)
Спасибо за Ваш труд! Жду с нетерпением следующее видео!
Супер! Много читал/смотрел из разных источников. И мало что понимал. Теперь почти всё понял. Спасибо!)
Спасибо! Может в будущих видео будет время рассказать о low, high level modules. Пока что нет четкого понятия. Супер что будут уроки по TypeScript!
Подумаю
Спасибо за видео. Было бы прикольно посмотреть все эти принципы в функциональном программирование)
Пожалуйста
Принцип инверсии зависимостей - хороший принцип, главное не увлекаться уровнями абстракций.
Спасибо большое за видео!
Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ...
Ждем продолжения серии ! :)
Спасибо!
Супер , я вообще не знал что есть такие понятия. Случайно наткнулся та это видео. Спасибо большое))
Принцип подстановки Барбары Лисков - хороший принцип. На практике, обычно, соблюдается сам собой. В голове держать надо.
Как раз то, что искал - спасибо!
Классно объяснил! Спасибо. Все очень понятно. Зачот!
Спасибо! Полезная информация!
огромное спасибо за видео! все по делу, понятно и без воды! очень благодарен!
Спасибо за отзыв)
Все здорово, но принцип Лисков не раскрыт, как и проблема квадрат прямоугольник. В вашем примере проблема осталась.
Подскажите где посмотреть более корректный пример?
@@user-vd9eu5vh5f если найдешь скинь пожалуйста)
@@user-vd9eu5vh5f ota-solid.now.sh/
ota-solid.now.sh/
Почему же осталась? Интерфейс создан, в каждом дочернем классе методы будут переопределены, и вызываться будет версия конкретного метода.
Спасибо за полезное видео. Интересно также увидеть как можно реально применить принципы solid в проекте например на react.
Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках.
Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова.
Но на реальных проектах в реальном мире, - я вас умоляю.
Мужик, очень здорово объяснил. Чудесная подача материала, ты большой молодец, продолжай в том же духе)
Успехов!
Спасибо большое
спасибо!
Пожалуйста
Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)
а еще лучше , если это Typescript, добавить интерфейс/абстактный клас, который будет содержать метод getPrice.
@@dmytrokucheriavyi605 А этого в этом видео разве не делает автор?
Согласен. Пример с ценами крайне неудачный
Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.
@@user-tq9ho2dp5p в твоём случае ты о шарпе, так.
Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID
Спасибо за отзыв)
Круто, спасибо за видео
Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)
Спасибо тебе друже! Очень рад что нашел твой канал хотя не часто захожу сюда и как вижу зря!
Спасибо, очень круто, думаю на repeat будет долго))) про ооп было бы тоже не плохо в таком формате:) огромное спасибо!
Спасибо за видео, отличное объяснение.
Пожалуйста)
Особлива подяка за приклади на TS
👍
Просто и понятно, супер пояснение, спасибо!
Пожалуйста)
Понравилось, спасибо! Лисков немного подкачал.... палец вверх!
Спасибо, очень коротко, доступно и понятно
Пожалуйста)
Супер
Коротко и ясно
Спасибо
Очень качественное обьяснение спасибо огромное !!!)))
Пожалуйста!
Классное видео! Спасибо за работу!
Пожалуйста
Как всегда годно)
Идеально понятное объяснение принципа SOLID, оргомнейший лайкос !!!
Спасибо
"Реально хочу надеяться..." клевый оборот речи
🤣
👍
👍
действительно просто, подписчиков мало
ещё бы разобрать grasp и gof
Нормально подписчиков для it канала, очень хороший результат
Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!
Пожалуйста. Язык TypeScript - он просто добавляет типизацию
Спасибо за классный разбор принципов SOLID
Спасибо за отзыв
Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.
Спасибо, ждем следующий видео))
за теслу лайк) А объяснение очень компатное и понятное, спасибо)
Спасибо
Спасибо, всё предельно понятно)
Пожалуйста
И все таки спасибо мне как раз для собеседования и нужно было хоть какое то представление иметь))
Действительно крутые рекомендации.
Смотрю и вижу свои будущие проблемы в коде. Сразу разведу и проблем не будет.
Пока смотрел поймал себя на мысли, что теперь я пишу код так. Кто я после этого. Это же совершенно другой уровень. Спасибо Евгений за контент.
Полюбому надо посмотреть еще пару раз и повторить руками.
Спасибо большое за отзыв
Отличный и понятный ролик
Ничего не понятно, но очень интересно. Видимо я один тут плохо понимаю объяснение. Судя по всему надо ООП в js хорошо знать.
OOP в JS? :D
в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе
Отлично объяснил. Спасибо!
Пожалуйста
спасибо, то что нужно
Спасибо! Очень круто! Наберусь наглости и нескромно спрошу: а по SSR (в частности по Next.js) у тебя нет планов на курс?
Есть, возможно, даже в этом году появится курс
OK!
👍
Дякую
Пожалуйста
Спасибо, интересно послушать о solid с примерами на родном js)
Я ж объяснил в самом начале, почему описанные подходы проблематично показывать на JS). Там везде только объекты, максимум класс. Ни абстракций, ни интерфейсов
@@YauhenKavalchuk , имел ввиду typescript, конечно. Спасибо, что поправили
Спасибо.
Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату
¯\_(ツ)_/¯
Спасибо огромное!
Пожалуйста
В Liskov subtitution подразумевается же, что класс-наследник не должен менять при переопределении поведение метода родительского класса
Никак не въезжаю. То ли примеры такие подбирают везде дурацкие, то ли идея сама по себе непонятная, то ли я чего-то не понимаю.
Из всех примеров, какие я встречал по всему интернету, я могу сделать только один вывод: принципы эти сводятся к тому, чтобы превратить простую парадигму класс-наследник-объекты в чрезмерно разветвлённую структуру из бесконечно растущего количества наследников, отличающихся порой только значениями свойств.
Если кто-то реально использует эти принципы, приведите, пожалуйста, пару-тройку примеров, где и почему вы их используете?
самый лучший примеры для таких принципов слишком сложны для понимание к примеру исходные коды фреймворов Laravel и Symfony и они в открытом доступе, просто наследуешь базовой контроллер и твой контроллер превращается в супер мутант монстра который способен на все, аналогично работает все компоненты этих фреймворков
Да, принцип подстановки Лисков всё-равно не понял. Но в любом случае, спасибо за старания
Отличное видео, вкратце и понятно, но думаю разрабам с низким уровнем будет сложновато, и возможно стоит посмотреть более подробный разбор принципов
👍
Готовлюсь к собеседованию и такие видео очень сильно помогают огромное спасибо
Пожалуйста
У вас очень крутой канал, спасибо за ваш труд.
У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?
А зачем вам тогда функция? У вас есть класс, который уже отдаёт цену
Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему.
А так в целом, хороший видос, много полезного узнал. Спасибо.
Пожалуйста
Спасибо за видио, с меня лайк.
Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса
Вы как раз описали почему)
Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс
Принцыпы сухпайка)
?
крутой
Спасибо
Спасибо за видео
Пожалуйста
Спасибо
13:55 оговорка про реализацию в интерфейсе
🤔
Хорошее объяснение. Не зная тайп скрипт я даже всё понял. Про OCP только поверхностно. Как расширять классы не рассказал
Основы чистой архитектуры
Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )
Ну нет интерфейсов, это не проблема. Используйте всё с классами)
9:52 в итоге проблема с 9:30 ведь осталась.
Подскажите где посмотреть более корректный пример?
@@user-vd9eu5vh5f В wikipedia идеальное описание этого принципа
Спасибо, Чувак!
Пожалуйста
Не думали о том, чтобы выпускать курсы на udemy? У вас отлично получается)
Нет не думал и не планирую
Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо
Ну по сути можно, но это уже нарушает принцип ООП об абстракции
Невероятно !! )
👍
огромное спасибо!
Пожалуйста
Хороший видос
Предлагаю тему к следующему видео: Просто о шаблоне MVC
👍 ну да, как вариант
10:21 Сущности не должны зависеть от интерфейсов , которые они используют? Или которые не используют? Или которые они не используют?
сущности НЕ должны зависеть от интерфейсов, которые НЕ используют
Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков.
У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?
You did a great job 👍
Thanks
Про grasp ещё можно рассказать
👍
А в javascript есть что-то похожее на interface и implement или есть какой-то способ их имитации?
Нет. В JS это всё классы
Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость
@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...
@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают
13:08 прошупрощения, не понимаю почему в параметры конструктура передается интерфейс с модификатором private
kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/
Принцип открытости и закрытости - тут нужно ловить баланс. Пример, изменился функционал цены, что лучше? Бегать по всем классам и изменять? Или, как в "неправильном примере", в одном классе в одной функции поменять. Очень сложный вопрос! Если функционал сложный и имеет множество условий в плоть до комбинаторики, то лучше разнести по классам. Если логика попроще, лучше запихнуть в один класс. Еще ошибка - решать данный принцип классами, а не структурой данных. В правильном примере зачем создавать кучу классов? Когда можно решить вопрос объектом содержащим все цены с ключами ссылками, при этом цикл гонять не надо {audi:{tradePrice:100, retailPrice:200}, bmw:{tradePrice:150, retailPrice:250}}. Ну и принцип O противоречит принципу S разбивая функциональность на несколько классов.
6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута
Как можно установить такой же стиль оформления кода для VS Code. Кто знает, подскажите, плиз)
О Г О Н Ь !
👍
Самое интересное что если отказаться от TS обратно к JS то это все будет не нужно. )))
Статическая типизация - напридумывали себе проблем а потом героически боремся с ними.
Ну, как есть
10:00 в коде ошибка, написано
interface Figure {
setWidth(width: number): void;
setHeight(width: number):void;
}
А должно быть setHeight(height: number): void;
Да, пропустил( Исправлю в репозитории
Начало 1:48
👍
А вот по принципу Single Responsibility, сколько методов может содержать класс?
Сколько угодно, ограничений нет. Главное что-бы класться отвечал за что-то одно