@@SurenKhorenyan У вас там два разных метода, с разными названиями (для кота и льва) и их вызов в сторонней ф-ии. Это проблема никак не связана с принципом Барбары Лисков, это просто какая-то сторонняя проблема в коде которая могла возникнут по десятку причин (ошибка проектирования интерфейса, проблема отсутствия адаптеров, нарушение связанности слоёв абстракции и пр.). Принцип Барбары Лисков гласит, что не стоит изменять функционал наследника так, чтобы его использование вместо родителя приводило к ошибкам или не очевидному поведению. Пример: у вас есть класс Person с методом moveForward(), который перемещает персонажа на клетку вперёд. Потом вы создаёте наследника StandingNPC extends Person и у него переопределяете метод moveForward() так что он никак не перемещает персонажа. Вот это и есть нарушение принципа Барбары
@@mzaytsev Спасибо, это хороший пример! Я не догадался привести такой пример, в будущем учту. Надеюсь, зрителю будет понятна сама идея и в том виде, что я показал
@@SurenKhorenyan На всякий случай отпишу лучше ещё тут вторую ошибку. Принцип разделения интерфейсов он не в выделении общего наследника и превращении его в интерфейс (это не верное понимание интерфейса), а в выделении множества интерфейсов на каждую характеристику будущего класса. Класс - это всегда некоторая сущность (даже если класс абстрактный) Интерфейс - это характеристика (в вашем примере это было бы два интерфейса, что-то вроде SmsSendible, EmailSendible) и уже имплементация каждого интерфейса в классах PDA, Smartphone и пр. Однако на этом примере сложно понять в чём плюс этого подхода, его легче рассмотреть на примере когда возникает проблема необходимости множественного наследования, аля Horse extends Animal, Vehicle
Интерфейс сам по себе подразумевает, что это только описание, мы там ничего не храним. Ну и посмотрите на лампочку. Она сама по себе не хранит информацию о том, включена ли. Эта информация в выключателе
Думаю, на деле функция включения лампочки будет реализована конкретно под лампочку, а не под все световые приборы. Хотя мб в рамках одного производителя и под все)
Всё зависит от ситуации. Лампочка же тоже бывает разная. Или представьте у вас дома один выключатель для лампочки, а другой для вентиляции. Выключатели же одинаковые. Так и в коде может быть пересечение. Но в частных случаях, конечно, может быть по-разному
Хмм, а что именно было непонятно? Неужели "вообще ничего непонятно"? Про какой принцип было непонятно? Догадываюсь, что если вы совсем не знаете про классы, то сложно понять всё, что было про наследование. Может быть понятие интерфейсов не очень понятно. А ещё?
@@АндрейСусарев-ю3л ничего страшного! Я рад объяснить, вы только скажите, что именно непонятно. Соглашусь, если вы только-только начинаете, может быть не всё понятно. Но когда вы будете сталкиваться с подобными проблемами, уже будете узнавать в них знакомые паттерны и легче находить решение
Лисков не о том, а о замене функциональности в наследнике
Так я же как раз показываю, что можно заменить содержимое метода в наследнике, главное чтобы он был совместим с тем, что ожидается от родителя 🙂
@@SurenKhorenyan У вас там два разных метода, с разными названиями (для кота и льва) и их вызов в сторонней ф-ии. Это проблема никак не связана с принципом Барбары Лисков, это просто какая-то сторонняя проблема в коде которая могла возникнут по десятку причин (ошибка проектирования интерфейса, проблема отсутствия адаптеров, нарушение связанности слоёв абстракции и пр.).
Принцип Барбары Лисков гласит, что не стоит изменять функционал наследника так, чтобы его использование вместо родителя приводило к ошибкам или не очевидному поведению.
Пример: у вас есть класс Person с методом moveForward(), который перемещает персонажа на клетку вперёд. Потом вы создаёте наследника StandingNPC extends Person и у него переопределяете метод moveForward() так что он никак не перемещает персонажа.
Вот это и есть нарушение принципа Барбары
@@mzaytsev Спасибо, это хороший пример! Я не догадался привести такой пример, в будущем учту. Надеюсь, зрителю будет понятна сама идея и в том виде, что я показал
@@SurenKhorenyan Удачи вам Сурен
@@SurenKhorenyan На всякий случай отпишу лучше ещё тут вторую ошибку.
Принцип разделения интерфейсов он не в выделении общего наследника и превращении его в интерфейс (это не верное понимание интерфейса), а в выделении множества интерфейсов на каждую характеристику будущего класса.
Класс - это всегда некоторая сущность (даже если класс абстрактный)
Интерфейс - это характеристика (в вашем примере это было бы два интерфейса, что-то вроде SmsSendible, EmailSendible) и уже имплементация каждого интерфейса в классах PDA, Smartphone и пр.
Однако на этом примере сложно понять в чём плюс этого подхода, его легче рассмотреть на примере когда возникает проблема необходимости множественного наследования, аля Horse extends Animal, Vehicle
Канал очень классный как для продолжающих так и для новичков, каналу желаю только роста ❤
Спасибо огромное!
Супер контент, как всегда, собственно.
Сурен, просто молодец
@@timurotube спасибо большое! Очень приятно 🥰
Супер контент, жду побольше подобного) особенно может быть что-то связанное с fast json api
спасибо! про FastAPI JSON:API обязательно сделаю ролики. мы как раз сейчас готовим крупное обновление библиотеки, будет о чем рассказать 🙂
12:21 почему нельзя хранить состояние о включение в самом интерфейсе и его реализациях?
Интерфейс сам по себе подразумевает, что это только описание, мы там ничего не храним. Ну и посмотрите на лампочку. Она сама по себе не хранит информацию о том, включена ли. Эта информация в выключателе
крутые примеры, но я помню их не понимал до определенного опыта. было приятно вспомнить
Спасибо! Да, хоть какое-то понимание программирования нужно, чтобы понять примеры
Спасибо, заценила мем с котом)
Хаа, пожалуйста!
Спасибо 🤝💪👍
Пожалуйста!
Думаю, на деле функция включения лампочки будет реализована конкретно под лампочку, а не под все световые приборы. Хотя мб в рамках одного производителя и под все)
Всё зависит от ситуации. Лампочка же тоже бывает разная. Или представьте у вас дома один выключатель для лампочки, а другой для вентиляции. Выключатели же одинаковые. Так и в коде может быть пересечение. Но в частных случаях, конечно, может быть по-разному
Я всегда думал что D это don't repeat yourself
Ещё было бы неплохо на реальных примерах разобрать
@@bernardsoul8936 да, вполне
рассказываете топ, но очень быстро, на 0.75 скорости смотрится хорошо
Хах, извините 😅
Хорошо, что есть замедление
Как все это ПОНЯТЬ ?!!! (Новичку) 😂😂😂😂😢
Хмм, а что именно было непонятно? Неужели "вообще ничего непонятно"? Про какой принцип было непонятно? Догадываюсь, что если вы совсем не знаете про классы, то сложно понять всё, что было про наследование. Может быть понятие интерфейсов не очень понятно. А ещё?
@@SurenKhorenyan я только начинаю входить в программирование. Поэтому мне и не понятно. Простите.
@@АндрейСусарев-ю3л ничего страшного! Я рад объяснить, вы только скажите, что именно непонятно. Соглашусь, если вы только-только начинаете, может быть не всё понятно. Но когда вы будете сталкиваться с подобными проблемами, уже будете узнавать в них знакомые паттерны и легче находить решение
Со временем будет понятнее и понятнее, просто продолжайте развиваться, изучать чужой код, и разрабатывать свой, и все придет со временем!
@@archi-zeus всё так! Главное не останавливаться