Свойства и их абстракции.

[kolas]

Xaositect в сообщении #385700 писал(а):

Правильно, но если у эллипса был такой метод, и он отнаследуется, то он будет неправильно работать у круга

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

[Xaositect]

kolas в сообщении #385703 писал(а):

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

Гм.
Я не могу переопределить метод void Ellipse::stretchX(double scale) так, чтобы он соответствовал своему названию (и предназначению).
Тут не переопределять надо, а рефакторить.

[kolas]

Xaositect в сообщении #385704 писал(а):

Гм.
Я не могу переопределить метод void Ellipse::stretchX(double scale) так, чтобы он соответствовал своему названию (и предназначению).
Тут не переопределять надо, а рефакторить.

Кстати, для таких скользких случаев можно использовать паттерн - декоратор, тогда можно будет развязаться от прямого наследования. Например:
еллипс -> фигура
круг -> фигура
круг <>-> еллипс

Далее конструктор круга принимает объект эллипс, и имеет только свойство - радиус, которое определяет свойства длина и высота у эллипса. Все остальные абстрактные методы класса фигуры, круг делегирует эллипсу.

[Xaositect]

В итоге вместо простой и понятной вещи [круг -> эллипс] получаем лишний класс и кучу кода.

Здесь надо просто делать, чтобы метод stretchX возвращал результат типа Ellipse. Мы с Joker_vD просто пытались объяснить, что некоторая проблема здесь за этим стоит.

[kolas]

Xaositect в сообщении #385709 писал(а):

Здесь надо просто делать, чтобы метод stretchX возвращал результат типа Ellipse

Ну и отлично, тогда у эллипса нужно сделать, чтобы методы stretchX и stretchY возвращали объект типа эллипс. У эллипса они будут реализованы так:
virtual Ellipse stretchX(value)
{
width = value;
return this;
}
...

у круга:
override Ellipse stretchX(value)
{
width = value;
return new Ellipse(width, hiegth);
}
....
double Radius
{
get{return radius;}
set{radius = value; width = value; hiegth = value;}
}

[Xaositect]

Да, это я и имел в виду. Заметьте, что вместо модифицирующего метода мы сделали немодифицирущий.
В итоге так можно и до функционального программирования и иммутабельности дойти :)

[kolas]

Xaositect в сообщении #385721 писал(а):

Заметьте, что вместо модифицирующего метода мы сделали немодифицирущий.

Да, но все равно это свойство (Radius) делегирует свою функциональность базовым(width, hiegth), так что правило подстановки работает.

Xaositect в сообщении #385721 писал(а):

В итоге так можно и до функционального программирования дойти :)

Согласен, да все едино, эти две парадигмы есть модель нашего мышления, т.е. это две реализации одной абстракции ;)

[Munin]

kolas в сообщении #385676 писал(а):

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

Человек даже не догадывается, что это некорректно, что за такие "сеттеры" руки вырывают.

Что позволено в графредакторе, не позволено в программировании, при оговорённых постусловиях и побочных эффектах.

[arseniiv]

(Оффтоп)

Munin в сообщении #385759 писал(а):

Человек даже не догадывается, что это некорректно, что за такие "сеттеры" руки вырывают.

Правильно. Надо говорить мутатор (и аксессор).

Шутка, конечно.

[Munin]

(Оффтоп)

Даже если это мутатор, за него руки вырывают. В базовом классе контракт (инвариант) этого мутатора состоял в том, что вторая полуось эллипса не меняется. Он предлагает в производном классе его нарушить. Верный путь обрушить клиента.

[arseniiv]

(Оффтоп)

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

P. S. Эти мудрёные слова я сам только несколько дней назад узнал.

[kolas]

Munin в сообщении #385908 писал(а):

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

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

-- Сб дек 11, 2010 16:53:45 --

Munin в сообщении #385908 писал(а):

В базовом классе контракт (инвариант) этого мутатора состоял в том, что вторая полуось эллипса не меняется.

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

[Munin]

kolas в сообщении #386078 писал(а):

Это называется не нарушить, а переопределить, это вполне нормальная практика в ооп, называется полиморфизм.

Это называется нарушать. В ООП нарушение контрактов нормальной практикой не является. Полиморфизм - это совсем другое, его роль как раз в выполнении контрактов.

kolas в сообщении #386078 писал(а):

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

Нет, просто ваша безграмотность оказалась всеобъемлющей. В программировании вы не знаете элементарных вещей точно так же, как и в физике.

[worm2]

kolas, Вы действительно не знаете, что наследование квадрата от прямоугольника нарушает принцип подстановки?

Английская википедия про известную проблему «Круг — это не эллипс» писал(а):

The circle-ellipse problem... illustrates the difficulties which can occur when a base class contains methods which mutate an object in a manner which might invalidate a (stronger) invariant found in a derived class, causing the Liskov substitution principle to be violated.

-- Сб дек 11, 2010 16:29:18 --

Виноват, есть ещё более подходящая ссылка:

Английская Википедия про принцип подстановки писал(а):

A typical example that violates LSP is a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height.... This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e. keep the dimensions equal), then these methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently.

-- Сб дек 11, 2010 16:38:11 --

Ну, и до кучи ещё ссылочку кину:
Из Marshall Cline's C++ FAQ про правильное проектирование наследования.

[kolas]

Munin в сообщении #386095 писал(а):

В ООП нарушение контрактов нормальной практикой не является. Полиморфизм - это совсем другое, его роль как раз в выполнении контрактов.

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

worm2 в сообщении #386100 писал(а):

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

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