ни разу не видел))

2018-ый год

больше по lighting ?)

ну так это уже тоже какой-нибудь 15-ый год

А где написано, что kiss - только про удобство интерфейсов? По-моему, это более общий случай

2018-ый год

я вживую только в этом году и увидел

А где написано, что kiss - только про удобство интерфейсов? По-моему, это более общий случай

можешь погуглить первоисточник

и он не про удобство интерфейсов а про... защиту от дурака если хочешь

ну то есть, когда штука не допускает или минимизирует некорректное использование

это ж не из программирования принцип а обще инженерный

можно проследить историю оного к 60-ым в среде любителей собирать истребители

и под kiss там подразумевалось возможность починить сломанный истриьбитель обычными инструментами

и это сложно

еще есть GRASP

simple != easy

и там тоже есть как многие думают "простые" для понимания и применения принципы

почему их не включили в статью?

почему их не включили в статью?

каплинг и кохижен включили)

но короч статья ниочем

это такой конспект двоешника

так это тот же чувак то статью про типизацию на той неделе написал))

тот же чувак, что и ссылку на статью дал :)

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

очень просто на классах: все наследники должны быть совместимыми с базовыми классами

если у тебя есть function (BaseClass x) { ... }, то ты туда сможешь передать любого наследника и все будет хорошо

понятно?

А если там свойство и метод переопеределены?

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

Он (LSP) не ХОРОШО, он НАДО. Это не для программистов, чтобы делали так или не делали так. Это основной принцип ООП (один из), он более для дизайнеров языков и объектных систем.

Просто смысл делать Базовый и под класс если они полностью совпадают?

Просто смысл делать Базовый и под класс если они полностью совпадают?

Кто тебе сказал, что они полностью совпадают?

никто. но если вдруг?

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

Ты в большинстве языков и случаев их использования НЕ МОЖЕШЬ нарушить этот принцип.

никто. но если вдруг?

Если вдруг, то и наследоваться нет смысла

наследоваться никогда нет смысла

наследоваться никогда нет смысла

не начинай заново вчерашнее :)

Он (LSP) не ХОРОШО, он НАДО. Это не для программистов, чтобы делали так или не делали так. Это основной принцип ООП (один из), он более для дизайнеров языков и объектных систем.

я правильно понимаю что для тебя любой вариант достижения подтипов = наследование?

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

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

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

ну то есть вот пример

Ты в большинстве языков и случаев их использования НЕ МОЖЕШЬ нарушить этот принцип.

как раз в большинстве языков ты можешь его нарушить очень просто)

и собственно если подставить под класс вместо базового в функцию - это же ее может крашнуть. или нет.

и собственно если подставить под класс вместо базового в функцию - это же ее может крашнуть. или нет.

если ты соблюдаешь контракты - то нет

в чем тогда смысл LSP?

в чем тогда смысл LSP?

в том что бы делать качественные абстракции данных

я правильно понимаю что для тебя любой вариант достижения подтипов = наследование?

Нет

если ты соблюдаешь контракты - то нет

не сбивай молодого человека страшными словами типа "контракты" :)

и собственно если подставить под класс вместо базового в функцию - это же ее может крашнуть. или нет.

Так о том как раз LSP и говорит, что НЕ ДОЛЖЕН (в корректной программе)

в чем тогда смысл LSP?

в том, чтобы не крешнуть

в чем тогда смысл LSP?

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

не сбивай молодого человека страшными словами типа "контракты" :)

да не, если для понимания LSP необходимо понимание контрактов - я изучу этот термин глубже))

в чем тогда смысл LSP?

Ну почитай что ли что-то ... кроме чатов.

да не, если для понимания LSP необходимо понимание контрактов - я изучу этот термин глубже))

Не нужны там контракты.

Не нужны там контракты.

нужны

ну то есть для понимание LSP нужно понимать что такое пред/пост условия и инварианты

хотя бы на примитивном уровне

это для глубокого понимания

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

Вот. Теперь Понял.

это для глубокого понимания

Слишком ветвисто получилось. Еще раз что там нужно для глубокого понимания?

ну то есть для понимание LSP нужно понимать что такое пред/пост условия и инварианты

а вообще-то нужно не это, а другое: понимание теории типов, что такое подтип и выводимости формул

это для глубокого понимания

ну в целом да, в целом большинству хватит "если я могу подменить и ничего не сломается - то все хорошо"

во!

ну то есть для понимание LSP нужно понимать что такое пред/пост условия и инварианты

Блин, ну не надо выдумывать.

давайте сегодня про что-то другое поспорим

давайте про OCP

например, чем OCP отличается от принципа: "публикуй интерфейсы, а прячь реализацию"

А мона еще чутка про LSP?))

вроде ж уже обсудили :)

ERROR: S client not available

тот же чувак, что и ссылку на статью дал :)

?

Я просто хочу методом уточки чирикнуть в чат свое понимание (теперь) LSP, но боюсь меня тапками закидают))

давай

наливай

LSP - если делаешь базовый класс (или абстракцию всех подкласов?). Делай так что бы все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. Так? Если нет, то где ошибка?

я вживую только в этом году и увидел

Welcome!:)

Welcome!:)

о

Ага:)

LSP - если делаешь базовый класс (или абстракцию всех подкласов?). Делай так что бы все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. Так? Если нет, то где ошибка?

Нет, не так. Ты добавил какие-то ненужные требования.

Нет, не так. Ты добавил какие-то ненужные требования.

какие?

например, чем OCP отличается от принципа: "публикуй интерфейсы, а прячь реализацию"

OCP = information hiding

LSP - если делаешь базовый класс (или абстракцию всех подкласов?). Делай так что бы все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. Так? Если нет, то где ошибка?

Тебе (если позволяет язык) нужно только соблюдать простое правило: не нарушать в наследниках "контракт" базового класса на работу с ним . Я написал "контракт" в кавычках, потому что это — другой контракт, не тот , который подразумевает Сергей Протко

LSP - если делаешь базовый класс (или абстракцию всех подкласов?). Делай так что бы все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. Так? Если нет, то где ошибка?

LSP это когда клиентскому коду который завязан на какой-то тип не важно с каким именно подтипом оно работает

LSP - если делаешь базовый класс (или абстракцию всех подкласов?). Делай так что бы все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. Так? Если нет, то где ошибка?

Вот это все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. лишнее.

LSP это когда клиентскому коду который завязан на какой-то тип не важно с каким именно подтипом оно работает

Вот это хорошее определение.

Вот это все что потом будет работать с подкласами опиралось на структуру базового класса (или абстракции) и при обработки разных подкласов не крашилось. лишнее.

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

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

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

Отличаться и противоречиь - разные слова

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

только то поведение которое важно для клиентского кода. То есть противоречие будет как раз в том что твой подтип вернет например что-то неожиданное

есть еще такой - robustness principle

хотя вариант @fes0r конечно более верный) я подразумевал что "внутренне" поведение подкласов может отличатся (и по идее должно) а вот "внешнее" должно быть одинаковым у всех подкласов одного базового класса. верно?

хотя вариант @fes0r конечно более верный) я подразумевал что "внутренне" поведение подкласов может отличатся (и по идее должно) а вот "внешнее" должно быть одинаковым у всех подкласов одного базового класса. верно?

да

Ура! Осилил))

иначе твой "полиморфизм" будет не убирать ифы а плодить их

Мэтры, что по теории типов и категорий почитать?

хотя вариант @fes0r конечно более верный) я подразумевал что "внутренне" поведение подкласов может отличатся (и по идее должно) а вот "внешнее" должно быть одинаковым у всех подкласов одного базового класса. верно?

Блин, а как ты "внутреннее" и "внешнее" поведение отличать собираешься, если у нас объекты, а у них ООП, и что там внутри, вообще говоря, неизвестно...

внешнее - это интерфес(методы которые можно дернуть) извне

Блин, а как ты "внутреннее" и "внешнее" поведение отличать собираешься, если у нас объекты, а у них ООП, и что там внутри, вообще говоря, неизвестно...

так и отличать, то, что известно = внешнее

Мэтры, что по теории типов и категорий почитать?

я не мэтр, но чувак с хабра пишет свой учебник + общается с аудторией активно

https://github.com/George66/Textbook

https://github.com/George66/Textbook

А по теории типов?

За ссылку спасибо