Liskov Substitution Principle и кругоэлипс

Что значит «классическая задачка, в которой круг нельзя наследовать от эллипса»? Что это за задачка? «Круг нельзя наследовать от эллипса» - это условие задачки? А откуда оно взялось? Ну хорошо, если такое условие - ну не наследуйте, в чём проблема непонятно.

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

А в каком месте при наследовании круга от эллипса нарушается этот самый LSP? И о каких методах идет речь?

>Теперь, есть классическая задачка, в которой круг нельзя наследовать от эллипса, потому что нарушается LSP

Нельзя, если объект мутабельный. Ежели нет — наследуйте на здоровье.

Предположим, что объект мутабельный. Что делать с дублированием кода?

>Предположим, что объект мутабельный.

Если мутабельный, то наследовать нельзя.

Что делать с дублированием кода?

Можно вынести иммутабельный интерфейс и реализовывать его и в эллипсе, и в круге (это безопасно). Весь код, который можно реализовать средствами этого интерфейса будет повторно используемым. Прочий код придется отдублировать (что и будет ИМХО семантически верно,).

let it be

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

Пока не ломаются инварианты, ничего не нарушается. Пока не определено поведение, ни о каком принципе не может быть и речи.

LSP это проблема имплементации, а не иерархии классов.

Ничего не понял, но ты путаешь круг и окружность :)

> Пока не определено поведение, ни о каком принципе не может быть и речи.

Object Oriented Programming == Behavior Oriented Programming?

> LSP это проблема имплементации

LSP - это не проблема, это базовый принцип :3

OOP == BOP

Что-то я начинаю сомневаться в авторитетности источников, из которых ты узнал про LSP. Хотя дело, скорей всего, в неправильной интерпретации.

LSP - это не проблема, это базовый принцип :3

Это становится проблемой, когда реализация его нарушает, очевидно же.

Уточняю твою позицию :)

Можете поделиться, как разруливать такие ситуации с дублированием кода расово-верно? На примере того же эллипса и круга.

Это же даже на википедии разжевано?

если наследник не может реализовать какой-то метод (он не имеет для него смысла)

читай у Коплиена про анализ изменчивости (в частности, про отрицательную изменчивость)

Я думаю lsp нужно свести к теории множеств, групп, теории категорий и т.д вверх по абстракции. Хотя, может jtootf даст комментарий?

Ух ты, имеется в виду «Мультипарадигменное проектирование для C++. Библиотека программиста», заценю асап

Во-первых используй где можно агрегацию вместо наследования. Во-вторых старайся по чаще использовать иммутабельные объекты. В-третьих это вообще проблемой особо не является. Например в жаве есть интерфес Collection. Представь, что в коде, использующем Collection я поменяю реализацию с ArrayList на HashSet. Тут не много другая проблема, правда. Нельзя безопасно менять реализации Collection, так как этот интерфейс нихрена не задает контракт, поэтому поведение полностью зависит от реализации. Тем не менее все нормально живут с этим Collection.

ITT ООП-петушары опять кудахчут про свои выдуманные проблемы.

В то время как GADT-БОГИ ржут над их никчемностью.

>>Теперь, есть классическая задачка, в которой круг нельзя наследовать от эллипса, потому что нарушается LSP

Нельзя, если объект мутабельный. Ежели нет — наследуйте на здоровье.

накоенц то. я пытался это доказать пару лет толпе(на sql.ru) а они кричали, а что если изменится сторона(там был квадрат прямоугольник) я им код на си++ писал, всеравно не понимали о чем я

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

Элементарные проблемы решаются элементарно. Это тебе не костыли для выдуманных проблем ООП-фимозников.

Да, элементарно решили - ввели в компилятор ghc понятие экзистенциальных типов, например :)
Так и на любом ЯП можно «элементарно» проблемы решать :)

>для выдуманных проблем ООП Тут ты частично прав.

Теперь, есть классическая задачка, в которой круг нельзя наследовать от эллипса, потому что нарушается LSP. Несмотря на то, что круг - частный случай эллипса.

Просто эллипс нужно наследовать от круга. Если класс «круг» содержит поле «радиус», то наследованный класс «эллипс» будет содержать поле «радиус» (вписанного или описанного круга), и «другой радиус» (большой или малый, соответсвенно).