Здравствуйте, VoidEx, Вы писали:

VE>Наследованием реализуют обычно, если что-то связано _не только_ IS, но и EXTENDS. Не даром там такое слово.

Где по этому поводу можно что-нибудь почитать?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Smal, Вы писали:

S>>В общем-то бинарная операция по определению замкнутая (т.е. является отображением M x M -> M). Другими словами, деление на множестве натуральных чисел не бинарная операция

I>Интересно, а если результат операции в некоторых случаях не определен (как при делении на нуль), можно ли называть операцию бинарной?
Однозначно нет. Поэтому деление на множестве вещественных — не бинарная операция.

Здравствуйте, Smal, Вы писали:

S>Однозначно нет. Поэтому деление на множестве вещественных — не бинарная операция.

Вот как. А англоязычные в Википедии своей заблуждаются или у них множество другое? Или определение бинарной операции?

Many binary operations of interest in both algebra and formal logic are commutative or associative. Many also have identity elements and inverse elements. Typical examples of binary operations are the addition (+) and multiplication (*) of numbers and matrices as well as composition of functions on a single set.

Examples of operations that are not commutative are subtraction (-), division (/), exponentiation(^), and super-exponentiation(@).

(http://en.wikipedia.org/wiki/Binary_operation)

Или тут не о бинарной операции, а об операции вообще? Зачем тогда в статье "Binary operation"?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Smal, Вы писали:

S>>Однозначно нет. Поэтому деление на множестве вещественных — не бинарная операция.

I>Вот как. А англоязычные в Википедии своей заблуждаются или у них множество другое? Или определение бинарной операции?

I>

I>Many binary operations of interest in both algebra and formal logic are commutative or associative. Many also have identity elements and inverse elements. Typical examples of binary operations are the addition (+) and multiplication (*) of numbers and matrices as well as composition of functions on a single set.

I>Examples of operations that are not commutative are subtraction (-), division (/), exponentiation(^), and super-exponentiation(@).

I>(http://en.wikipedia.org/wiki/Binary_operation)

I>Или тут не о бинарной операции, а об операции вообще? Зачем тогда в статье "Binary operation"?

Не ошибаются, а недоговаривают. Деления — это бинарная операция на множестве вещественных чисел без нуля (R\{0}).

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, FDSC, Вы писали:

FDS>>Вы сказали чушь откровенную. Настолько, что я так и не смог написать вам ответ с опровержением. Так что спасибо igna за то, что выразил мои мысли.

VE>Все множество прямоугольников шире, чем множество квадратов, так что квадраты — это специализация прямоугольников (когда стороны равны), а вовсе не расширение, и наследование здесь ни при чем.


Наследование, в частности, применяется, когда нужна специализация более общего класса. Например, есть список, который сортирует с указанием функции сравнения, а мы его специализируем для более удобного и безошибочного использования в сортировщик без указания функции сравнения или со стандартным набором функций сравнения (что бы пользователь не мог ошибочно указать неправильную функцию).
При этом, в некоторых случаях объект базового класса вполне может себя вести как объект производного класса — если мы поставили туда соотв. функцию сравнения. В то же время, наследование может происходить здесь и наоборот, от списка с жёстко заданным сортировщиком, к списку с указанием функции сравнения. Всё зависит от того, для чего мы это хотим сделать и что в данной конкретной системе будет являться повышением удобства или гибкости программирования.

Здравствуйте, jedi, Вы писали:

jedi>Навскидку: окружность и эллипс

Так и кто от кого тут будет наследоваться???

Здравствуйте, igna, Вы писали:

Реализация механизма наследования в популярных языках не всегда удачно эмулирует отношение "is a". Например, если твой экземпляр прямоугольника имеет одинаковые стороны, то он должен приводиться к классу квадратов, ромбов и т.д. В CORBA есть возможность перехватить вызов метода is_a(Type) и сделать, например, порождение экземпляра-прокси, отвечающего нужному интерфейсу.

В терминах .Net для преобразования типов твоих фигур можно ввести доп. метод:

public interface Figure {
    T IsA<T>() where T: Figure;
}

public interface Rectangle : Figure {
    int Width { get; }
    int Height { get; }
}

public interface Square : Figure {
    int Size { get; }
}

public class Figure4 : Figure {
    public T IsA<T> where T: Figure {
        if(T is Square 
             && Size0==Size1 && Size0==Size2 && Size0==Size3 
             && Angle0==90) // в градусах например
            return new SqareImpl(this.Size0);
            
        ...
        return null;
    }
}

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, jedi, Вы писали:

jedi>>Навскидку: окружность и эллипс

FDS>Так и кто от кого тут будет наследоваться???

Хм, если ты не заметил, то это были как раз примеры ситуаций, где наследование не только полезно, но и вредно
Однако, если следовать логике топикстартера, то нужно наследовать окружность от эллипса, ибо окружнось IS эллипс, у которого большая и малая оси равны. Говорят этот иогурт особенно хорош, когда окружность неизменна

Здравствуйте, igna, Вы писали:

I>Здравствуйте, jedi, Вы писали:

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

I>У такого наследования нет никаких "подводных камней" в отличие от наследования в случае, когда фигуры изменяемы.

У такого наследования нет нетолько "подводных камней", но и смысла

Smal,

I>>Или тут не о бинарной операции, а об операции вообще? Зачем тогда в статье "Binary operation"?

S>Не ошибаются, а недоговаривают. Деления — это бинарная операция на множестве вещественных чисел без нуля (R\{0}).

маленькая придирка: сказанное тобой означает, что

(/) :: (R\{0}) x (R\{0}) -> (R\{0})

в то время как обычно предполагается определение

либо
(/) :: R x (R\{0}) -> R
либо
(/) :: (R_+) x (R_+) -> (R_+)
где R_+ ::= R + {Infinity, -Infinity, NaN}

причём предпочтительнее именно второй вариант — операция деления становится замкнутой.

Эта особенность отражена и в стандарте IEEE 754 — реализации "вещественных чисел" на железках.

Здравствуйте, jedi, Вы писали:

J>Однако, если следовать логике топикстартера, то нужно наследовать окружность от эллипса, ибо окружнось IS эллипс, у которого большая и малая оси равны. Говорят этот иогурт особенно хорош, когда окружность неизменна

Не передергивай, "этот иогурт" только тогда и возможен, "когда окружность неизменна". Хорош-нехорош, а также осмыслен или нет, это другие вопросы.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, MouseEntity, Вы писали:

I>

ME>>r = Rectangle(100, 100);
I>

I>А что, если класс Square не производить от класса Rectangle, то r сразу перестанет быть квадратом с математической точки зрения или станет им с точки зрения системы типов?

Нет

Здравствуйте, MouseEntity, Вы писали:

I>>А что, если класс Square не производить от класса Rectangle, то r сразу перестанет быть квадратом с математической точки зрения или станет им с точки зрения системы типов?

ME>Нет

А как же определить типы Square и Rectangle, чтобы можно было не нарушая "приличий" написать

r = new Rectangle(100, 100);

?

Здравствуйте, igna, Вы писали:

I>А как же определить типы Square и Rectangle, чтобы можно было не нарушая "приличий" написать

I>

I>r = new Rectangle(100, 100);
I>

I>?

Можно использовать преобразования типов, придётся кидаться исключениями в случае если width != height, но похоже это неполное решение. А можно вообще отказаться от типизации или не разделять квадраты и прямоугольники на разные типы.

Здравствуйте, MouseEntity, Вы писали:

ME>Можно использовать преобразования типов, придётся кидаться исключениями в случае если width != height, но похоже это неполное решение. А можно вообще отказаться от типизации или не разделять квадраты и прямоугольники на разные типы.

А если вместо квадратов и прямоугольников речь о квадратных и прямоугольных матрицах, и функция вычисления детерминанта (определителя) имеет смысл только для квадратных матриц? Определить только прямоугольную матрицу, определить функцию вычисления детерминанта для нее и "кидаться исключениями" в случае вызова этой функции для неквадратной матрицы?

Здравствуйте, igna, Вы писали:

I>Это может привести к неправильному поведению, или тут только избыточность?
Избыточность, плюс мне лично кажется очень нелогичным такое:

void foo (Square const & sq) { ... }

void test
{
  Rectangle rect(2, 2);
  foo (rect); // Почему нет?
}

Тут объект базового класса (т.е. созданный как Rectangle) явно является и объектом Square, однако языком это никак не выражается.

I>Где по этому поводу можно что-нибудь почитать?
Конкретно не скажу, может быть, даже и нет такого. Может, это только мое мнение))
Но вот у Страуструпа точно есть про то, что окружность не надо наследовать от эллипса.
Лично мне кажется, что наследование должно именно расширять множество, т.е. например "Кнопка с текстом" наследуется от "Кнопка". Множество всех кнопок с текстом (в том числе и с пустым) будет шире, чем множество всех простых кнопок (без текста).
Ессно, что это теория, и вообще наследование надо использовать так, как оно удобно.
В случае с прямоугольником/квадратом мне неудобно именно то, что Rectangle(2,2) не эквивалентен Square(2), хотя вообще говоря, это одно и то же.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, VoidEx, Вы писали:

FDS>Всё зависит от того, для чего мы это хотим сделать и что в данной конкретной системе будет являться повышением удобства или гибкости программирования.

Само собой, гибкость, это хорошо, но я говорил с позиции.. философии что ли.

Здравствуйте, VoidEx, Вы писали:

VE>Конкретно не скажу, может быть, даже и нет такого. Может, это только мое мнение))
VE>Но вот у Страуструпа точно есть про то, что окружность не надо наследовать от эллипса.
VE>Лично мне кажется, что наследование должно именно расширять множество, т.е. например "Кнопка с текстом" наследуется от "Кнопка". Множество всех кнопок с текстом (в том числе и с пустым) будет шире, чем множество всех простых кнопок (без текста).
VE>Ессно, что это теория, и вообще наследование надо использовать так, как оно удобно.
VE>В случае с прямоугольником/квадратом мне неудобно именно то, что Rectangle(2,2) не эквивалентен Square(2), хотя вообще говоря, это одно и то же.

Воовбще-то множество кнопок шире, чем множество кнопок с с текстом.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, VoidEx, Вы писали:

FDS>>Всё зависит от того, для чего мы это хотим сделать и что в данной конкретной системе будет являться повышением удобства или гибкости программирования.

VE>Само собой, гибкость, это хорошо, но я говорил с позиции.. философии что ли.

С позиции философии наследование есть всего лишь наследование реализации и интерфейса.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, igna, Вы писали:

I>>Это может привести к неправильному поведению, или тут только избыточность?
VE>Избыточность, плюс мне лично кажется очень нелогичным такое:

VE>

VE>void foo (Square const & sq) { ... }

VE>void test
VE>{
VE>  Rectangle rect(2, 2);
VE>  foo (rect); // Почему нет?
VE>}
VE>

VE>Тут объект базового класса (т.е. созданный как Rectangle) явно является и объектом Square, однако языком это никак не выражается.

Естественно, не выражается. Так как здесь прямоугольник СЛУЧАЙНО стал квадратом, в результате некоторых вычислений, которые вы заменили Rectangle rect(2, 2), иначе программист должен был бы просто сделать Rectangle rect = new Square(2);
Т.е. не нужно путать случайное совпадение параметров и СТАТИЧЕСКИ гарантированный тип данных.

I>>Где по этому поводу можно что-нибудь почитать?
VE>Конкретно не скажу, может быть, даже и нет такого. Может, это только мое мнение))
VE>Но вот у Страуструпа точно есть про то, что окружность не надо наследовать от эллипса.
VE>Лично мне кажется, что наследование должно именно расширять множество, т.е. например "Кнопка с текстом" наследуется от "Кнопка". Множество всех кнопок с текстом (в том числе и с пустым) будет шире, чем множество всех простых кнопок (без текста).

Т.е. вы предлагаете наследовать прямоугольник от квадрата???