Принцип подстановки Барбары Лисков || The Liskov substitution principle

Сегодня мы рассмотрим еще один реальный фронтендерский пример основанный на SOLID принципе, а именно "Принцип подстановки Барбары Лисков". Казалось бы JS это не ООП, но это не значит, что мы не можем перенять суть принципа на свой манер
The Liskov substitution principle - ru.wikipedia.org/wiki/%D0%9F%...
Поддержать Айти Синяка можно здесь:
KZbin: / @it-sin9k
boosty: boosty.to/sin9k
Patreon: / itsin9k
Таймкоды:
00:00 Объявление темы
00:22 Определение принципа
00:51 Разберемся на утках
01:45 Как это работает в JS?
02:00 Классическая история создания IconButton
03:49 Почему так не стоит создавать IconButton
04:50 IconButton и принцип подстановки Барбары Лисков
08:00 Мы осовременили данный принцип
08:34 Подписывайтесь!
08:44 Рекомендованные видео
Подписаться на канал: / @it-sin9k
Twitter: / it_sin9k
-------------------------
Данный канал создан для инициирования бесед на различные темы IT сферы (социальные / технические), а также для тех кому короткая видео выжимка статьи, выступления на конференции или же просто личных мыслей, являются более удобным форматом

[@Kirshach]

У тебя лучшее объяснение принципов SOLID что я видел) спасибо

[@it-sin9k]

Спасибо за такую высокую оценку!)

[@krumbo]

200%, I have never seen someone explains SOLID at front end so well

[@Epenckorn]

Немчинского посмотри. А это - дичь какая-то.

[@LRXAORLOV]

Одно из простых объяснений что я слышал) спасибо :)

[@sawyerreign6628]

I know Im randomly asking but does someone know of a trick to log back into an Instagram account..? I was dumb forgot the account password. I would love any assistance you can offer me.

[@sawyerreign6628]

@Pedro Leonard I really appreciate your reply. I got to the site through google and Im in the hacking process now. Looks like it's gonna take a while so I will reply here later with my results.

[@sawyerreign6628]

@Pedro Leonard It worked and I finally got access to my account again. I'm so happy:D Thanks so much, you really help me out :D

[@pedroleonard2007]

@Sawyer Reign No problem :)

[@spadar1602]

Ты просто открытие, обязательно порекомендую твой канал в ld

[@it-sin9k]

Спасибо!)

[@lomeat]

оо, был такой опыт на проекте. Буквально была кнопка и я как хороший программист, пытался учесть все возможные способы ее использования, от чего пропсы кнопки дико росли с каждой последующей версткой новых компонентов. А потом пришел лид и сказал "убери это нахер и делай отдельные компоненты таких кнопок". Я тогда послушался, но не понял смысла такого сокращения. В целом там это и было не так реализовано, как тут в видео и уже сейчас я ясно представил, как это все еще можно было упростить и улучшить. Но я только сейчас понял, как важно понимать все принципы. Ну еще важно обьяснять почему надо делать, а не так. Если бы он мне сразу тогда донес свою мысль, то мне не пришлось бы узнавать случайно прямо сейчас.

[@it-sin9k]

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

[@romanmed9035]

@@it-sin9k зато Вас интересно слушать и подача материала все же необычная. потому и смотрю Ваши выпуски (и не только их конечно), когда необходимо на что-то отвлечься.

[@it-sin9k]

@@romanmed9035 Спасибо!

[@user-cd1sr5sx2r]

Спасибо. Одно из самых понятных объяснений этого не простого принципа.

[@bizuha]

Очень интересное и подробное объяснение. Большое спасибо за проделанный труд!

[@user-wk5ij2je3z]

Спасибо за Ваши труды! Наверное самое для меня интересное в фронтенде- применять паттерны проектирования, принципы ООП Контент мега полезный!

[@andreyshevchenko4602]

отличное обьяснение!! Все круто, продолжай в том же стиле!

[@it-sin9k]

Спасибо! Лучшая благодарность для нашего канала, это поделиться этим видео с коллегами

[@turuturuururur8691]

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

[@dmitry4337]

Не очень то и гибкий подход. Вы унаследовали DefaultIconButtonWithBadge от DefaultIconButton. Но что, если в будущем и у CallIconButton появится badge? Придется создавать еще один дочерний класс. На практике это все может перерасти в кучу параллельных иерархий с дублирующимся кодом. А в остальном видео - огонь, очень доходчиво объясняете.

[@user-pm4wq2rv9h]

Спасибо за урок!

[@sergey_llal6897]

спасибо за прекрасную подачу

[@dgtlist]

Огромное спасибо за инфо. Помогает мне подобрать принцип сборки дизайн-системы в Figma

[@yuragrivicki5272]

Лучшее объяснение, ты крут!!! И для Ютубчика SOLID - principle of Barbara Liskov.

[@TheTexPro]

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

[@apanchuk]

Спасибо. Подобный подход в построение UIKit обдумываю уже какое-то время.

[@it-sin9k]

мы рады быть полезными)

[@dimitro.cardellini]

А вот здесь хорошо! Даже отлично. Очень правильно было отойти от привязки к наследованию классов. Здесь яркий пример создания под-типов без классов и без наследования.

[@spoonjeee4785]

Спасибо, полезно

[@AndriyEismond]

Привет. Круто! Отличное объяснение!

[@it-sin9k]

Привет) Спасибо за фидбек!

[@user-cq3hr5op5q]

Отличное объяснение ! Апплодисменты !

[@it-sin9k]

Спасибо!)

[@GagikHarutyunyan_dev]

По этому и CSS это CSS (Cascading Style Sheets), на наследовании весь CSS, и до css in js или модулей нужно было писать так чтобы не конфликтовали и плюс расширялись. Спасибо за урок

[@zizzxiii2714]

Наконец-то я понял. Спасибо ! Все понятно!

[@it-sin9k]

Всегда пожалуйста ;-) Приходите еще)

[@dmitrykorovin4356]

супер классно, спасибо

[@xD-hu3gw]

звучит все так просто ) как слышу меняем дизайны всех кнопок - у меня глаз дергается )

[@it-sin9k]

ахах) нужна практика) как за рулем)

[@imvasia13]

Вероятно, самое лучше объяснениє, которое я слышал :) Спасибо!

[@it-sin9k]

высокая похвала! спасибо!)

[@avtandilshainidze7160]

Присоединяюсь к предедущим комментам. Одно из простейщих обяснении, да еще и с анимашками )))

[@it-sin9k]

Спасибо!) мы очень стараемся) особенно сейчас тренируем разные визуальные плюшки, чтобы было смотреть приятнее)

[@yuriiyurii6656]

Супер

[@mykhailostepanishchev6472]

крутой видос,спс !

[@daryashashko6688]

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

[@it-sin9k]

не за что)

[@Kurama.00]

Я как бэкендщик (будущий) смотрю этот видос, и меня аж трясёт (мем с пёсиком: мхм-мхм, кнопочка должна теперь выводить циферки) Но видос полезный, ведь принцип работает одинаково и там, и там

[@NoName-zh7cc]

The best!

[@krumbo]

Thanks!

[@it-sin9k]

Первое супер спасибо! Низкий поклон!!!

[@igor_cojocaru]

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

[@it-sin9k]

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

[@igor_cojocaru]

@@it-sin9k Очень хочется поделиться с коллегами, но к моему сожалению они не знают русского языка.

[@it-sin9k]

мы начинали английскую версию, там даже приличное кол-во видео запаблишено) но из-за недостаточного английского и свободного времени, пришлось поставить на паузу, пока бюджет на это дело не появится) Пока вот пару видео можете пошарить коллегам) kzbin.info/www/bejne/eXqmq6Sqhs1_bbc

[@igor_cojocaru]

@@it-sin9k Спасибо! Круто что про Reconciliation есть на английском. Будем объяснять почему key важно делать уникальным. И вообще что там под капотом 👍🏻

[@it-sin9k]

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

[@pavell53]

Очень круто. Примеры приближенные к реальности. JS + верстка, а не тупо на JS принципы объяснены.

[@it-sin9k]

именно такую идею при создании видео я и пытался передать) я рад, что получилось)

[@vladimirrusov7842]

Очень интересно) Для добавления budge лучше сделать без создания новой кнопки, в просто добавлять кнопку в качестве children при использовании budge компонента?

[@it-sin9k]

в данной ситуации наверное да)

[@IFlexxx]

А чем эта эпопея с кнопками отличается от обычного наследования?

[@snatvb]

пример с наследованием кнопок идейно крут, но только для этого лучшего всего подойдет не наследование, а порождающие паттерны, например декоратор, а так же композиция таким образом ты делаешь "декоратор" - компонент обертку, Button, который выступает просто оберткой и получает children, потом ты делаешь кучу иконок и все такое, потом делаешь компонент "декоратор" WithBadge - который добавляет обертку твоему children и устанавливает бейджик в правом верхнем углу, теперь ты можешь это комбинировать - делать композицию: чем это лучше? завтра приходит дизайнер и говорит, что мне бы бейджик добавить для тэга, или аватарки пользователя, а ты просто берешь и оборачиваешь :) Composition > Extends

[@it-sin9k]

Декоратор всегда побеждает у наследования :)

[@user-ku2hc3mr3m]

Спасибо за видео! Вечно забываю смысл этого принципа из-за не очень говорящего названия) Получается, если следовать этому принципу, то базовая уточка не должна уметь летать? Или механической утки не должно существовать?

[@it-sin9k]

Оба варианта работают. Если базовая утка перестанет уметь летать, то принцип не будет нарушаться. Либо механическая утка не будет наследоваться от базовой утки.

[@it-sin9k]

Мне кажется, нам тяжело его запомнить, т.к. мы его не используем во фронтенде. Это на первый взгляд кажется вообще невозможным :)

[@Mirba_]

у меня такой вопрос, допустим у нас есть базовая кнопка: IconButton со своими стилями из ../UiKit/IconButton/style.css затем у нас появилась необходимость в новой кнопке: CallIconButton, и для этого мы создаем еще компонент CallIconButton куда подключаем стили из ../UiKit/CallIconButton/style.css, то есть каждый раз при необходимости мы создаем новый компонент с новыми стилями? я правильно понял?

[@it-sin9k]

Смотря в какой ситуации. Если вы хотите расширить функционал текущей кнопки, то создаете новую и дописываете ей нужные стили только. Есть еще один пример с попапами, где я делал по такому же принципу, может станет немного понятнее: kzbin.info/www/bejne/aGG9h4lrqs-efNk

[@makeoverweb2663]

подскажи пжл, я не совсем понял как создавать прототип функционального компонента, чтобы основываться на его текущей реализации и добавлять еще новую.У меня есть только идея делать это через HOC

[@it-sin9k]

Я обычно действую очень ситуативно. Например, если те же кнопки выглядят совершенно по разному, я бы разнес это просто в разные компоненты. Если же мы хотим просто добавить существующей кнопке, например состояние isActive (у самой кнопки физически такого состояния нет). Я возможно создал бы еще один компонент, который в return будет возвращать первоначальную кнопку и передал бы className ему что то типа такого classNames({ [styles.active]: isActive }). Таким образом кому нужна кнопка с активным состояние использовал бы эту кнопку, а кому состояние такое не нужно использовал бы базовую кнопку

[@makeoverweb2663]

@@it-sin9k неплохой вариант, спасибо за совет мистер Синяк)

[@apanchuk]

А как быть с изменениями в базовый компонент IconButton? Стараться не вносить изменения, а расширять его (знакомый принцип)? Ведь иначе придется проверять всех остальных потомков. Возможно тут будет полезно скриншот-тестирование. Сорри, если я пропустил ответ в видео)

[@it-sin9k]

идея таких подходов заключается в том, что чем ближе компонент к базовому, тем реже он должен изменяться. Если так не получается, вероятно либо у вас короткое дерево насследования, либо составлено не совсем удачно наследование. И конечно же скриншотное тестирование избавит вас от пробрем с регрессией. Однозначно рекомендую

[@ilyakushlianski6519]

Композиция компонентов или render props были бы даже лучшим вариантом, чем DefaultIconButtonWithBadge. Тут видится вообще 3 компонента: кнопка, внутренняя иконка и бэдж

[@it-sin9k]

Ага) разгонять можно сильно) в зависимости от нужд проекта)

[@user-ox4yl6gu3u]

Очередной годный контент! Очередной лайк Синяку! А ты реально пишешь на голом is, не на typescript даже?

[@it-sin9k]

Как какой проект, текущий на TS, предыдущие 2 были на JS.

[@serheliusperchuk5298]

Меня направили на этот канал на собеседовании. Вижу что не зря сходил на это собеседование))))

[@it-sin9k]

ничего себе)) а в каком городе нас так рекламируют?)

[@serheliusperchuk5298]

​@@it-sin9k Одна компания в Черновцах)

[@it-sin9k]

круто!) расширяем нашу географию)

[@dididie158]

Не совсем понял как размеры прокидываются, через IconButton или отдельно CallIconButton и отдельно defaultIconButton?

[@maksimmaksimenko3504]

Доброй ночи, можете объяснить что значит наследовать от базовой кнопки? Не могу понять как это происходит на практике. За ранее благодарю.

[@it-sin9k]

тут не столько был рассказ о насследовании, которое стоит использовать в повседневном проекте, сколько скорее рассказать про то как работает этот принцип. В данном случае "псевдо" наследование заключалось, что мы просто использовали кнопку как обычный компонент и добавляли какие-то дополнительные настройки

[@maksimmaksimenko3504]

@@it-sin9k понял Вас, спасибо большое за ответ и за видео которые Вы делаете

[@Quentinrei]

👋👋👋👋

[@qwe-rty-]

Так как реакт продвигает композицию вместо наследования, то это все у нас будут просто разные компоненты, так ведь? (Возможно только с общим файлом стилей, но разными .tsx файлами🤔)

[@it-sin9k]

Да, конечно это разные tsx файлы. Более подробно я разбирал как это может выглядеть на примере попапов в этом видео. Идея примерно такая же: kzbin.info/www/bejne/aGG9h4lrqs-efNk

[@dm.hol.3624]

Год не работал, смотрю перед серией собесов. Если поможет, подпишусь на донаты. Ну а пока лукас + коммент.

[@it-sin9k]

Перед собесами, лучше посмотреть тогда про React плейлист и доклад про React) Ждем и надеемся на донаты :D

[@bogdankarpus181]

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

[@it-sin9k]

На самом деле, то что обсуждается в этом видео, это скорее ближе к композиции чем к наследованию. Есть еще одно видео, в котором я использовал похожий подход, чтобы разложить попапы по полочкам) kzbin.info/www/bejne/aGG9h4lrqs-efNk

[@cikada3398]

Как быть с функциональными компонентами? Выносить логику в кастомные хуки? и дергать их у наследников?)

[@it-sin9k]

конкретно в данном кейсе, я рассматривал ui-kit. У ui-kit вроде как не должно быть логики

[@romanmed9035]

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

[@it-sin9k]

Спасибо за подробный комментарий :) Мы изначально решили делать контент направленный не на новичков, потому что для них материалов в интернете огромное количество. Идея видео была, скорее показать, как этот паттерн будет выглядеть в рамках фронтенда

[@romanmed9035]

@@it-sin9k спасибо, да заметно что все же не для нулевого уровня и это радует. ибо как устновить ноду и кра несколько десятков вариантов.

[@LRXAORLOV]

Да и где поддержать можно )?

[@it-sin9k]

мы пока еще не рассматривали варианты для пожертвований) но для нас особое значение имеет то, что наш контент вызывает желание поддержать проект!) Это вероятно лучшая похвала) Спасибо!)

[@LRXAORLOV]

Если будете выбирать посмотрите buymeacoffee) а то у patreon большие проценты) Рубрика незваные советы ;)

[@it-sin9k]

Спасибо за совет) о таком не знал даже) будем изучать вопрос)

[@it-sin9k]

Привет) мы прислушались к твоему вопросу и создали целых 2 площадки для поддержки проекта, возможно разным людям в разных местах удобнее поддерживать) Если еще есть советы по тому как мы оформили или выставили настройки дай знать) Поддержать проект можно здесь: Patreon: www.patreon.com/ITSin9k BuyMeACoffee: www.buymeacoffee.com/XcBPY5W

[@ruslanaskarov5393]

не совсем понятно как расширять базовую кнопку

[@banderlogUA]

Создаём обычную кнопку с минимальным набором стилей и пропсов, для расширения оставляем две вещи: динамический класс и контент кнопки как children, для кнопки с иконкой мы прокидываем иконку в children, и если нужно красить то прокидываем модифицирующий класс

[@username8836]

Просто прочитай 2 принцип солид. и все

[@user-ti7sq3qe6u]

механическая? я думал это утка зомбарь

[@it-sin9k]

ахаха) я как раз смотрел в те времена "живые мертвецы" или как он там называется))

[@user-pg8ry1tm3t]

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

[@pavel.karpets]

Но ведь изначально не использовалось вообще никакого наследования. Т.е принцип не нарушался - его просто негде было применить. Потом автор внедрил наследование сразу с применением LSP. По-моему не очень показательно. ps: а вот пример с утками зачётный

[@VladimirS.-sk5kh]

Да неужели хоть кто-то нормально объяснил!

[@eugenebores]

По-моему принцип подстановки Барбары Лисков тут притянут за уши. Я его понимаю как наследуемый класс не должен расширять интерфейс, а только менять поведение базового интерфейса, чтобы можно было указывать в аргументах базовый класс или интерфейс. В приведённом примере и близко нет такого требования, везде используется конкретная имплементация. В итоге получили несколько параллельных иерархий: обычные иконки, иконки с бэджами и иконки для звонков -- а дальше все остальные комбинации. Это очень плохое решение, сам обжигался на нём несколько раз. Лучше иметь иерархию новых признаков, чем несколько иерархий с признаками (см. паттерн мост).

[@it-sin9k]

Хмм, я вот перечитал несколько раз. Возможно я ошибался в понимании этого принципа. Попробую на свежую голову почитать побольше :) Спасибо за комментарий!

[@user-jx9rw3ip6w]

isDisabled?! ты че серьезно?

[@username8836]

Автор явно не читал 2 принцип солид

[@Epenckorn]

Я, конечно, не претендую на истину в последней инстанции, но возьму на себя смелость высказать конструктивную критику. Во-первых, краткая формулировка принципа подстановки от Роберта Мартина на человеческом языке - "функции, использующие базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом". Во-вторых, этот принцип описывает правильный полиморфизм, а не правильное наследование. В-третьих, лично я вообще против этого принципа, так как он ломает напрочь саму основу ООП. И я не могу придумать ситуацию, когда может понадобится внезапно подставлять подкласс туда, где изначально был родительский класс. Если вам внезапно в объекте родительского класса понадобился метод одного из его наследников, значит у вас что-то не так с архитектурой приложения. В-четвёртых, проблема с появлением кнопки с количеством пользователей решалась добавлением 2 свойств, которые нужно было предусмотреть ещё на этапе добавления свойства theme, а именно добавить свойство css_class вместо theme и content вместо badge, а в них уже в виде объектов хранить и тему и тип контента (bagde/numbers/emoji) и сам контент. В-пятых, на кнопках звонка badge тоже нужен. Как ты дашь понять пользователю, что его микрофон выключен или за(mute)н или камера не определяется или поставлена на паузу? В-шестых, в качестве цветовой темы правильнее и логичнее использовать переменные css, а не свойства в коде js. В-седьмых, обнуление css-свойств для класса - это, конечно, ни разу не нарушает принцип reuse, да... размещение шрифтовой иконки в виде тега вместо псевдоэлемента before с абсолютным позиционированием - это, конечно, сильно... Но спишем это всё на демонстрационный пример. Дальше я уже окончательно перестал понимать, что происходит на экране и кто все эти Button. Резюмирую. Мне больно смотреть, как люди надрачивают на одну из букв твердотельника с сомнительной полезностью, при этом просирая наглухо принципы DRY, разделения ответственности между представлением и логикой, здравого смысла и юзабельности собственного инструмента.

[@johnins1646]

Объяснение не корректное, по сути вы привели пример наследования. ЛСП говорит о нарушении контракта.