SOLID: Принцип подстановки Барбары Лисков/ LSP (The Liskov Substitution Principle)

А как на счет предпочитайте композицию наследованию?

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

Паттерн Proxy порушує принцип "The Liskov Substitution Principle"? Адже ми змінюємо роботу базового класу для додавання додаткової логіки.

Это для чего тогда наследование, если потомок можно закинуть в код работающий с родителем? Ну, давай приведи пример!

И что делать с квадратом? 😅

С квадратом все вроде понятно что так получается криво. А как отнаследовать квадрат, иак чтобы он: а) не нарушал LSP, б) оставался квадратом и в) не превращался в прямоугольник?

про TTD интересно

Мое дБ должна быть сделана с помощью мок апи, например mockito, jmock, easymock, etc Не надо самим эти сроки писать, ТК их количество будет рочти постоянно. Эти сроки тоже могут баги иметь. И тоже надо тестить)))

класс

Сергей, математики любят глазами а не ушами :) Если бы Вы записали принцип в трактовке Барбары на языке формул я думаю было бы значительно более понятно, чем со слов.

Разве mock не должен лежать в модуле test, недосягаемом для основного кода?

Слава России

Я знаю чому для Вас формулювання Барбари Лісков складне і заплутане! Все тому, що для Вас і квадрат - це не прямокутник!)
Дякую за відео. Приклад з квадратом підірвав мій мозок.

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

Я рукожоп на Си... )))

НАЗВАНИЕ SOLID -- это сексизм! 😂
ПРАВИЛЬНОЕ НАЗВАНИЕ -- SOSID
Substitution Principle вместо The Liskov Substitution Principle

как реализовать принцип барбары лисков LSP в языках в кот нет наследования go?

Я постараюсь привести пример проблематики соблюдения LSP принципа.
Допустим у вас есть класс Human. У этого класса есть такие поля как; пол, возраст, рост, вес и тд..
Теперь представим что у нас есть класс Student. В этом классе добавляется название колледжа, номер курса, и специальность.
Согласитесь что наследование студента от человека выглядит довольно безобидным и естественным. Ещё представим что в текущей версии кода есть метода которая вычисляет налог "социального страхования" для любого человека, и основана она только на возрасте человека.
Понятно что в текущей версии кода, LSP принцип соблюдается для этой методы.
А теперь представим что в будущем закон изменился и теперь студенты освобождены от оплаты налогов. С этого момента LSP принцип нарушен.
проблема здесь на самом деле глубокая и заключается она в том что если B наследует от A, то требуется доказать математически что B является A.
Дело в том что наследование Student от Human основывается на нашем естественном восприятии но в то же время плохо определено в математическом смысле.
Вся сложность LSP является в том что наследование должно быть корректно не только в текущей версии кода, но и во всех (неизвестно на сегодня) будущих его версиях.
Когда домейн классов находится в математической плоскости нам легче создать корректное наследование, но к сожалению это лишь малая часть всех проблем которыми мы занимаемся.
Отсюда вытекает общий антипаттерн наследования.

По моей оценке вся суть проблемы была не раскрыта.
Наследование как "анти паттерн", основана на сложности соблюдение LSP принципа.
Пройдёмся по примерам в этом ролике:
1. Здесь Сергей рассказывает как плохо нарушать LSP принцип и к чему это может привести. Но дело не в том что его нельзя явно нарушать (это и так понятно), а в том что его очень сложно соблюдать.
2. Сергей здесь спасибо вам за альтернативное определение LSP (оно добавляет глубины понимания!) хотя по моей оценке примеры всё равно слабы.
3. По моей оценке этот пример вообще не об этом. Здесь проблема не в соблюдении или несоблюдении LSP, а в отсутствии инкапсуляции. Это был хороший пример того что лучше писать иммутабильные классы а setters/getters могут раскрыть зачастую внутреннюю структуру класса.
С точки зрения наследования - это как раз один из немногих примеров где наследование является корректным. Наследования квадрата от прямоугольника является математически правильным и хорошо обоснованным с точки зрения качеств квадрата по отношению к качествам прямоугольника.Если бы состояние этих классов задавалось только при помощи конструктора, то никакой проблемы не было бы.

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

А про рукожопа було обідно....

Как я раньше не зnull об этом?

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

Хорошее видео, жду такое же про Оксимирона

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

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

Наконец-то я понял этот принцип)

Або це просто вже 100те відео про Лісков і я нарешті зрозумів, або це найкраще з тих відео що я бачив і я зрозумів =))

Писать юнит тесты на слой БД с моком той самой БД не имеет абсолютно никакого смысла. Это вредная, бесполезная работа. Что мы тестируем? как работает мок БД? Как ОРМ умеет собирать запросы в бд?
Вот именно. Тест слоя работы с БД только через интеграционные тесты.

Дуже вам дякую за пояснення. Все просто і зрозуміло )

(питання НЕ від програміста) Чи можуть класи-нащадки мати атрибути і методи (або якісь приховані властивості), яких немає в батьківському класі?
Справа в тому, що з одного боку квадрат - це лише окремий випадок прямокутника, а з іншого боку квадрат фактично має приховану властивість (в загальному сенсі, НЕ в сенсі атрибут класу), якої немає у прямокутника - що у нього суміжні сторони жорстко пов'язані (рівні) між собою.

Так какое решение с квадратом:?

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

А что с квадратом делать?

Супер, Сергей) Спасибо большое за видео, однозначно лайк!)

Прямоугольник расширяет квадрат, а не наоборот. Там само наследование не туда

Очень наглядное объяснение. Проще говоря, нужно наследовать большее от меньшего, а не наоборот. Все станет на свои места, если считать, что квадрат - это частный случай прямоугольника, а не его наследник. Именно такой подход применят учёные. Потому обьяснение Барбары и не понятно программистам с ООП профдеформацией. :)

Кстати, очень логична формулировка именно Барбары, с точки зрения теории типов…

Авторка🤦‍♂️

Я просто офигеваю от того, какой Сергей потрясающий интеллектуал. Мне страшно смотреть его видео. Страшно от того, что голова может лопнуть от обилия деталей, но потом трясущейся рукой тянусь и нажимаю кнопку начала просмотра, а потом инфа кое-как укладывается под отличную и ровную мелодию под методичный голос Сергея…
P.S. короче, как тупой я понял принцип LSP главным образом в том, что не должен наследуемый класс делать больше, чем его основной класс.

OK!

Когда встал вопрос о unit тестах, я засмеялся хахахахаха

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

Последний раз наследовался год назад
Сраный процедурщик (с)

Короче, если я правильно понял, этот принцип можно объяснить так: все реализации методов родителя должны быть взаимозаменяемы относительно этих же методов из других дочерних классов, а то бог Яхве, спустивший нам с небес 5 священных заповедей SOLID, сделает нам атата.

Интересно как его зовут спустя год после выхода видео

Нужны новые фломастеры

Это как сначало клас точка, потом линия, потом допустим тот самый прямоугольник(аналитическая геометрия), дальше в сторону усложнения, потомок дополняет родительский класс а не наоборот