ООП: что главнее, матрица или вектор

Цитата MyNameIsIgor @ 19.08.14, 16:29

Цитата Qraizer @ 19.08.14, 16:22

Классы будут вполне к месту, просто тут наследование нафик не сдалось

Прелестно - в предметной области сущности чётко связаны отношением "является", а у нас в программе - нет

Так разные там "являются". Ты ж сам про принцип подстановки упомянул

Цитата Pavia @ 19.08.14, 17:20

А нет их в предметной области

Чего нет в предметной области? Векторы и матрицы есть в предметной области.

Цитата Qraizer @ 19.08.14, 17:24

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

Уравнение - это поиск корней многочлена. А многочлен второй степени таки частный случай многочлена третьей степени с коэффициентом 0 у переменной в третьей степени.

Цитата Qraizer @ 19.08.14, 17:24

Операции умножения матриц и векторов -- это сильно разные операции

Если введён частный оператор для частного случая матриц, это не значит, что частный случай матриц - не матрица

Цитата D_KEY @ 19.08.14, 17:33

Так разные там "являются"

Ой ли?

Цитата D_KEY @ 19.08.14, 17:33

Ты ж сам про принцип подстановки упомянул

Ага. Давай вот на примере чисел: целые наследуются от действительных или действительные от целых? А комплексные?

А вообще прикольно как вы юлите И споры по предметной области (т.е. математике) сейчас пойдут, и попытки её натянуть на используемые принципы разработки. И всё только лишь для того, чтобы не признавать, что инструмент имеет ограничения и для подобных случаев не подходит.

Сообщение отредактировано: MyNameIsIgor - 19.08.14, 17:51

Цитата Qraizer @ 19.08.14, 17:24

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

Ещё как является. К-т при x^3 равен нулю.

Цитата lamer2 @ 19.08.14, 14:30

Цитата BlackEmperor @ 18.08.14, 20:25

Попробую тогда спросить: а что будет базой для чего - квадрат для прямоугольника или прямоугольник для квадрата?

Не любой прямоугольник - квадрат
Поэтому базовым будет прямоугольник.

Пусть так...
Предположим у прямоугольника есть методы получения длин его сторон GetA и GetB, которые для прямоугольника возвращают разные значения. Квадрат будучи потомком прямоугольника наследует методы, и оба метода возвращают теперь одно и то же значение (это же квадрат). Получаем избыточные методы. В коде так же есть путаница, кто-то для получения длины стороны квадрата вызывает GetA, а кто-то GetB. Получаем не очень хорошо читаемый код. Особого криминала нет, но есть неприятный мусор и каждая попытка как-то прикрыть этот мусор будет очередным костылем.
По Вашему мнению, все же квадрат и прямоугольник связаны и прямоугольник база для квадрата?

Цитата Qraizer @ 19.08.14, 17:24

Операции умножения матриц и векторов -- это сильно разные операции. Итп.

Операции одинаковые
Один из векторов надо "положить набок", и будет в чистом виде умножение матриц.

Цитата MyNameIsIgor @ 19.08.14, 17:50

Ага. Давай вот на примере чисел: целые наследуются от действительных или действительные от целых? А мнимые?

От простого к сложному. В математике от целых строться действительные и от них мнимые, а затеем кватернионы.

Но вот числа как раз таки исторически сгруппированы в единый класс и имеют общие функции операторы.

Цитата BlackEmperor @ 19.08.14, 17:52

Получаем избыточные методы. В коде так же есть путаница, кто-то для получения длины стороны квадрата вызывает GetA, а кто-то GetB.

Надо применить protected-наследование, чтобы у квадрата-наследника был доступен только метод GetA

Цитата BlackEmperor @ 19.08.14, 17:52

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

fixed

Цитата Pavia @ 19.08.14, 17:55

От простого к сложному

Впервые слышу такой принцип проектирования.

Цитата Pavia @ 19.08.14, 17:55

В математике от целых строться действительные и от них мнимые, а затеем кватернионы.

В таком направлении развивалась математика На самом же деле действительные - частный случай комплексных, а целые - частный случай действительных. А предложенная вами иерархия не отвечает принципу подстановки.

Цитата lamer2 @ 19.08.14, 17:53

Операции одинаковые
Один из векторов надо "положить набок", и будет в чистом виде умножение матриц.

Операции разные так как определения у них разные.
Более того я молчу что у матриц несколько операций умножения.
Если вы строите классы матрицы и вектора как дерево классов для тензерного вычисления, то тут ещё можно было бы согласиться. Но матрицы и вектора это не только тензоры они применяются для широкого круга задач. И функции и операции с ними очень различны. А процент общего очень мал.

Цитата lamer2 @ 19.08.14, 17:57

Цитата BlackEmperor @ 19.08.14, 17:52

Получаем избыточные методы. В коде так же есть путаница, кто-то для получения длины стороны квадрата вызывает GetA, а кто-то GetB.

Надо применить protected-наследование, чтобы у квадрата-наследника был доступен только метод GetA

Хорошо.
А если будет решено, что квадрат будет базой для некоторого объекта "крышка стола" и тут я опять получаю доступ к методам класса "прямоугольник", когорые были открыты / защищены и так же мне доступны при защищенном наследовании.
К тому же есть теперь побочный эффект, квадрат не приводится к прямоугольнику. Нормальное С++ приведение, а не С-каст, не даст привести указатель или ссылку в данном случае квадрата на прямоугольник, так как защищенное и закрытое наследование не дадут сделать такое приведение.
Получается, что квадрат - это уже не прямоугольник?

Цитата MyNameIsIgor @ 19.08.14, 17:50

Цитата D_KEY @ 19.08.14, 17:33

Ты ж сам про принцип подстановки упомянул

Ага. Давай вот на примере чисел: целые наследуются от действительных или действительные от целых? А комплексные?

А чего тебе наследоваться-то так хочется?

Цитата MyNameIsIgor @ 19.08.14, 17:50

Ага. Давай вот на примере чисел: целые наследуются от действительных или действительные от целых? А комплексные?

Принцип is A прекрасно помогает в данном случае.

Цитата D_KEY @ 19.08.14, 18:04

А чего тебе наследоваться-то так хочется?

Из-за чёткого отношения "является" в предметной области. Так что либо мы ему последовательно следуем в моделируемых сущностях, либо признаём, что ООП далеко не всегда позволяет удобно для человека отражать предметную область.

BlackEmperor, зависит от операций, которые ты определил для прямоугольника, квадрата и пр. Скажем, иммутабельный квадрат вполне себе иммутабельный прямоугольник

Цитата D_KEY @ 19.08.14, 18:06

BlackEmperor, зависит от операций, которые ты определил для прямоугольника, квадрата и пр. Скажем, иммутабельный квадрат вполне себе иммутабельный прямоугольник

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