Просто о SOLID (Принципы SOLID)
HTML-код
- Опубликовано: 2 июн 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
✒ Автор курса:
✔ RUclips: / yauhenkavalchuk
✔ Instagram: / yauhenkavalchuk
✔ Twitter: / yauhenkavalchuk
✔ VK: YauhenKavalchuk
✔ LinkedIn: / yauhenkavalchuk
✔ GitHub: github.com/YauhenKavalchuk
✔ VK (Группа): webdevcom
✒ Поддержать развитие канала: github.com/YauhenKavalchuk/yo...
![Darren Waller - Who Knew (Her Perspective) [Official Video]](http://i.ytimg.com/vi/GytDjB8u6bM/mqdefault.jpg)
Принципы SOLID можно изучать вечно и каждый раз познавать что то новое, особенно когда применяешь часто на практике) Спасибо!
Евгений выражаю вам мою искреннюю благодарность за ваш труд! Как всегда все коротко, информативно, и разложенно по полочкам, лайк без вопросов!
то чувство когда ты джун, тебе нужно знать все, зашел сюда, поставил лайк и решил, что на собесе скажу просто как это расшифровывается)
🤣
Сегодня на собеседовании слил этот вопрос) три тим лида ржали с меня
@@zakharkulbachenko3433 прошел собес?
@@DENDYTWOO видимо он умер
Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно
Спасибо! Может в будущих видео будет время рассказать о low, high level modules. Пока что нет четкого понятия. Супер что будут уроки по TypeScript!
Подумаю
Тема крутая. Однозначно лукас :)
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 Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо.
В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено
Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)
Отличное видео. Оно настолько минималистично, насколько это нужно, чтобы быть максимально понятным. Эталон. Спасибо.
Принцип инверсии зависимостей - хороший принцип, главное не увлекаться уровнями абстракций.
Спасибо коллега, побольше такого контента и если можно расскажи про CI/CD
Это следующее видео в этом плейлисте, проверяй!
Спасибо большое за видео!
Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ...
Ждем продолжения серии ! :)
Отличное объяснение, хоть и с нюансами некоторыми) спасибо, жду ещё видео такого формата
Принцип подстановки Барбары Лисков - хороший принцип. На практике, обычно, соблюдается сам собой. В голове держать надо.
Все здорово, но принцип Лисков не раскрыт, как и проблема квадрат прямоугольник. В вашем примере проблема осталась.
Подскажите где посмотреть более корректный пример?
@@user-vd9eu5vh5f если найдешь скинь пожалуйста)
@@user-vd9eu5vh5f ota-solid.now.sh/
ota-solid.now.sh/
Почему же осталась? Интерфейс создан, в каждом дочернем классе методы будут переопределены, и вызываться будет версия конкретного метода.
Спасибо за Ваш труд! Жду с нетерпением следующее видео!
Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)
а еще лучше , если это Typescript, добавить интерфейс/абстактный клас, который будет содержать метод getPrice.
@@dmytrokucheriavyi605 А этого в этом видео разве не делает автор?
Согласен. Пример с ценами крайне неудачный
Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.
@@user-tq9ho2dp5p в твоём случае ты о шарпе, так.
Спасибо за видео. Было бы прикольно посмотреть все эти принципы в функциональном программирование)
Пожалуйста
Супер! Много читал/смотрел из разных источников. И мало что понимал. Теперь почти всё понял. Спасибо!)
Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)
Спасибо!
Спасибо, очень круто, думаю на repeat будет долго))) про ооп было бы тоже не плохо в таком формате:) огромное спасибо!
Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID
Спасибо за отзыв)
Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.
Спасибо! Очень круто! Наберусь наглости и нескромно спрошу: а по SSR (в частности по Next.js) у тебя нет планов на курс?
Есть, возможно, даже в этом году появится курс
Супер , я вообще не знал что есть такие понятия. Случайно наткнулся та это видео. Спасибо большое))
В Liskov subtitution подразумевается же, что класс-наследник не должен менять при переопределении поведение метода родительского класса
Спасибо! Полезная информация!
Классно объяснил! Спасибо. Все очень понятно. Зачот!
Спасибо за полезное видео. Интересно также увидеть как можно реально применить принципы solid в проекте например на react.
Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках.
Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова.
Но на реальных проектах в реальном мире, - я вас умоляю.
спасибо!
Пожалуйста
Как раз то, что искал - спасибо!
У вас очень крутой канал, спасибо за ваш труд.
У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?
А зачем вам тогда функция? У вас есть класс, который уже отдаёт цену
Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату
¯\_(ツ)_/¯
Никак не въезжаю. То ли примеры такие подбирают везде дурацкие, то ли идея сама по себе непонятная, то ли я чего-то не понимаю.
Из всех примеров, какие я встречал по всему интернету, я могу сделать только один вывод: принципы эти сводятся к тому, чтобы превратить простую парадигму класс-наследник-объекты в чрезмерно разветвлённую структуру из бесконечно растущего количества наследников, отличающихся порой только значениями свойств.
Если кто-то реально использует эти принципы, приведите, пожалуйста, пару-тройку примеров, где и почему вы их используете?
самый лучший примеры для таких принципов слишком сложны для понимание к примеру исходные коды фреймворов Laravel и Symfony и они в открытом доступе, просто наследуешь базовой контроллер и твой контроллер превращается в супер мутант монстра который способен на все, аналогично работает все компоненты этих фреймворков
Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо
Ну по сути можно, но это уже нарушает принцип ООП об абстракции
Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )
Ну нет интерфейсов, это не проблема. Используйте всё с классами)
Мужик, очень здорово объяснил. Чудесная подача материала, ты большой молодец, продолжай в том же духе)
Успехов!
Спасибо большое
Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков.
У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?
Спасибо за видио, с меня лайк.
Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса
Вы как раз описали почему)
Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс
10:21 Сущности не должны зависеть от интерфейсов , которые они используют? Или которые не используют? Или которые они не используют?
сущности НЕ должны зависеть от интерфейсов, которые НЕ используют
огромное спасибо за видео! все по делу, понятно и без воды! очень благодарен!
Спасибо за отзыв)
"Реально хочу надеяться..." клевый оборот речи
🤣
У меня вопрос насчет принципа единственной ответственности (кстати, слова "единый" и "единственный" - паронимы, я бы не стал их взаимозаменять).
Итак,
"2:20 - итак принцип единой ответственности звучит он как у модуля должна быть только одна причина для изменения или класс должен отвечать только за что-то одно".
А вот цитата из Роберта Мартина "Чистая архитектура":
"Из всех принципов SOLID наиболее трудно понимаемым является прин цип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соот ветствующего сути. Услышав это название, многие программисты решают: оно означает, или класс должен отвечать только за что-то одно".
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы исполь зуем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID - это не принцип единственной ответственности."
Тут возникает сразу несколько вопросов, и самый первый - кому же верить?
Особлива подяка за приклади на TS
👍
Хорошее объяснение. Не зная тайп скрипт я даже всё понял. Про OCP только поверхностно. Как расширять классы не рассказал
действительно просто, подписчиков мало
ещё бы разобрать grasp и gof
Нормально подписчиков для it канала, очень хороший результат
А в javascript есть что-то похожее на interface и implement или есть какой-то способ их имитации?
Нет. В JS это всё классы
Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость
@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...
@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают
Ничего не понятно, но очень интересно. Видимо я один тут плохо понимаю объяснение. Судя по всему надо ООП в js хорошо знать.
OOP в JS? :D
в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе
6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута
Принцип открытости и закрытости - тут нужно ловить баланс. Пример, изменился функционал цены, что лучше? Бегать по всем классам и изменять? Или, как в "неправильном примере", в одном классе в одной функции поменять. Очень сложный вопрос! Если функционал сложный и имеет множество условий в плоть до комбинаторики, то лучше разнести по классам. Если логика попроще, лучше запихнуть в один класс. Еще ошибка - решать данный принцип классами, а не структурой данных. В правильном примере зачем создавать кучу классов? Когда можно решить вопрос объектом содержащим все цены с ключами ссылками, при этом цикл гонять не надо {audi:{tradePrice:100, retailPrice:200}, bmw:{tradePrice:150, retailPrice:250}}. Ну и принцип O противоречит принципу S разбивая функциональность на несколько классов.
Да, принцип подстановки Лисков всё-равно не понял. Но в любом случае, спасибо за старания
Принцип подстановки Барбары Лисков.
Я бы изобразил абстракцию реализовав в ней метод расчета площади и от неё наследовался бы, реализуя метод установки ширины и высоты.
Вопрос. Это же тоже сохраняет принцип подстановки. Нет?
Если я правильно понял описание, то нет
Круто, спасибо за видео
Не думали о том, чтобы выпускать курсы на udemy? У вас отлично получается)
Нет не думал и не планирую
Отличное видео, вкратце и понятно, но думаю разрабам с низким уровнем будет сложновато, и возможно стоит посмотреть более подробный разбор принципов
👍
Интерфейс это особеность тайпскрипта ? Или и в ванильном джс есть ? Походу настал момент когда мне надо освоить тайпскрипт. А что такое лоу и хай модуль, как понять, что он лоу или хай. Или вся разница в том кто кого включает в себя ?
Интерфейсов в JS нету.
В примере про общий интерфейс у фигуры не должно быть установки ширины и высоты, фигура может быть и окружность и треугольник. Там должен быть только метод получения площади.
👍
Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему.
А так в целом, хороший видос, много полезного узнал. Спасибо.
Пожалуйста
Спасибо тебе друже! Очень рад что нашел твой канал хотя не часто захожу сюда и как вижу зря!
А вот по принципу Single Responsibility, сколько методов может содержать класс?
Сколько угодно, ограничений нет. Главное что-бы класться отвечал за что-то одно
Понравилось, спасибо! Лисков немного подкачал.... палец вверх!
Спасибо за видео, отличное объяснение.
Пожалуйста)
Пример с квадратом считаю "высосанным из пальца"\некорректным
В функции setWidth можно было сделать "пустое" тело, у функции setHeight сделать только this.height = height, а также переопределить функцию areaOf: areaOf() { return this.height * this.height}
Тогда никаких ошибок бы не возникло
Возможно… но это самый распространённый пример
Во втором примере (принцип открытости \ закрытости) с тем же успехом я могу ведь просто не создавать никакой абстракции и все будет отлично работать, у меня тот же самый метод getPrice в каждом объекте. Объясните пожалуйста зачем она (абстракция) нужна?
Из другого ролика другого автора по этой же теме, я понял этот принцип так: класс должен быть ОТКРЫТ для расширения и ЗАКРЫТ для изменения (расширяем класс для внедрения нового, продвинутого функционала и при этом не изменяем базовый класс, на котором работает старый функционал. В итоге старый код с большей вероятностью продолжит работать без ошибок). Или я что то не правильно понял смотря это видео, или другой автор просто оказался ближе к истине.
Абстракцию можно и не создавать. Всё верно поняли - открыт для расширения, закрыт для изменения. Я ведь тоже делал акцент на этом)
10:00 в коде ошибка, написано
interface Figure {
setWidth(width: number): void;
setHeight(width: number):void;
}
А должно быть setHeight(height: number): void;
Да, пропустил( Исправлю в репозитории
Просто и понятно, супер пояснение, спасибо!
Пожалуйста)
Очень качественное обьяснение спасибо огромное !!!)))
Пожалуйста!
Спасибо, очень коротко, доступно и понятно
Пожалуйста)
Немного сбивает с толку пример со стоимостями машин:
Почему не сделать базовый класс с полем цены, метод getPrice() так же определить в базовом классе, а вариации (Audi, BMW) уже сделать наследниками, в которых переопределяется поле цены ?
И второй вариант вообще оставить один класс, а определять самоу стоимость в экземпляре (это вроде как не противоречит смыслу того, что машины стоят по разному)
*если что я в js не разбираюсь, но думаю наследование и перегрузка полей там есть ?
Супер
Коротко и ясно
Спасибо
Как всегда годно)
Принцыпы сухпайка)
?
Получается класс Rectangle ( в примере принципа Барбары Лисков ) противоречит принципу единственной ответственности? Ведь у него как минимум 3 метода для изменения
И кстати это вполне нормальная ситуация когда сделав код по одному принципу, конфликтуешь с другим. Но в примере противоречия нет - все 3 метода работают с параметрами одной сущности и нет каких-то «левых» манипуляций
@@YauhenKavalchuk Спасибо за ответ!
В этом случае непонятно тогда, в чем принцип единственной ответственности, если суть принципа: "Есть только один повод для изменения". Тогда нужно раскрыть более подробно принцип единственной ответственности.
( это не претензия, я не знаю как правильно, а наоборот пытаюсь понять )
спасибо за видео, но объяснение на тайпскрипт не подходит, например для меня. я понимаю что происходит но не по профилю идёт потеря понимания.
Нужны были примеры кода. Я не могу писать одни и те же имплементации на разных языках
Классное видео! Спасибо за работу!
Пожалуйста
"Аджайл" было бы неплохо поправить в описании.
Покоробило от абстрактного класса цены, унаследованного автомобилями.
Поправил
13:08 прошупрощения, не понимаю почему в параметры конструктура передается интерфейс с модификатором private
kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/
Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!
Пожалуйста. Язык TypeScript - он просто добавляет типизацию
13:55 оговорка про реализацию в интерфейсе
🤔
Идеально понятное объяснение принципа SOLID, оргомнейший лайкос !!!
Спасибо
Основы чистой архитектуры
9:47 и как это решает проблему?
У Square по-прежнему будут два метода setWidth и setHeight каждый из которых изменяет оба поля width и height?
Специально реализацию не написал, потому что пришлось бы это объяснять?))
Выглядит как-будто поменяли шило на мыло
Похоже, методы setWidth и setHeight нужно вовсе убрать из интерфейса Figure, так как они нарушают LSP. А вот areaOf не нарушает и его можно оставить.
Решить проблему можно было бы так:
- В Shape оставить только areaOF
- Для Rectangle нужно было бы создать интерфейс RectangleShape который был бы наследником Shape. А setWidth и setHeight вынести в RectangleShape
- для Square нужно было бы создать интерфейс SquareShape который был бы наследником Shape. В SquareShape добавить метод setSize.
- Таким образом если теперь в коде заменить все Shape на ReactangleShape или SquareShape поведение программы никак не изменится.
Спасибо, ждем следующий видео))
Про grasp ещё можно рассказать
👍
Zdorovo!
Tol'ko u menya voprosov stalo bol'she?
¯\_(ツ)_/¯
Спасибо, всё предельно понятно)
Пожалуйста
Вот вроде бы понимаю все, но при написании программы не могу применять этот ООП, выходит процедурный способ всегда
🤔🤷♂️
"L": не сразу понял, но потом дошло! совместимость это да, это правильно! гласное не нарушать при этом "S" (не штамповать "универсальных солдат" в коде)!
👍
9:52 в итоге проблема с 9:30 ведь осталась.
Подскажите где посмотреть более корректный пример?
@@user-vd9eu5vh5f В wikipedia идеальное описание этого принципа
И все таки спасибо мне как раз для собеседования и нужно было хоть какое то представление иметь))
Предлагаю тему к следующему видео: Просто о шаблоне MVC
👍 ну да, как вариант
А зачем на скриншоты листингов приклеен какой-то светофорчик вверху?
Для красоты
@@YauhenKavalchuk да, красота требует жертв.
за теслу лайк) А объяснение очень компатное и понятное, спасибо)
Спасибо
Почему в примиере Лисков не использовать абстрактный класс для фигур?
Решил не усложнять дополнительной абстракцией
👍
👍
Самое интересное что если отказаться от TS обратно к JS то это все будет не нужно. )))
Статическая типизация - напридумывали себе проблем а потом героически боремся с ними.
Ну, как есть
спасибо, то что нужно
Как можно установить такой же стиль оформления кода для VS Code. Кто знает, подскажите, плиз)
Отличный и понятный ролик
Брат, Tesla implement CarPrice, не extends. (Потому что твой абстрактный класс и метод не несет никакой реализации)
Да ты ушел от того что не нужно делать фактори, но ты должен добавлять элемент в массив, что тоже является изменением кода. Самое простое сделать менеджера. Который принимает интерфейс класса CarPrice и выдает цену при вызове метода любого класса описанного этим интерфейсом для примера. А конеркретная реализация того как выбрать определенный авто это уже реализация конеткрной задачи.
Класс для каждого типа авто? Даже не знаю, стоит ли дальше смотреть...
Вроде все так знакомо, но синтаксис какой-то непонятный ... не C++ ли это часом?
TypeScript