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

Здравствуйте, уважаемые программисты
Очевидно, что в ООП реализации жданных сущностей одно должно быть наследником другого.
Матрица это вектор векторов. С другой стороны вектор это матрица Nx1.
Что правильнее сделать бызовым классом - вектор или матрицу?

Ни то, ни другое. Если нечто выглядит похожим на что-то, это не значит, что они как-то должны быть связаны. Пример прям по горячему: матрица -- это вектор векторов; как сделать класс производным от самого себя?

Наследование определяется по правилу is A
Матрица является вектором
Но и вектор является матрицей. Как выбрать что от чего наследовать?

Холивара намечается?

Цитата lamer2 @ 18.08.14, 18:23

Что правильнее сделать бызовым классом - вектор или матрицу?

Базовым - вектор, ящетаю!

Цитата lamer2 @ 18.08.14, 18:23

Очевидно, что в ООП реализации жданных сущностей одно должно быть наследником другого.

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

Цитата Qraizer @ 18.08.14, 18:26

Если нечто выглядит похожим на что-то, это не значит, что они как-то должны быть связаны.

Думаю, что именно этим и надо пользоваться в данной ситуации ...

Сообщение отредактировано: BlackEmperor - 18.08.14, 20:26

Зависит от того, что моделируем.

Я смотрю, некто из семейства вуйкообразных таки развёл вас на тему-постонабивалку

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

Цитата Yakudza @ 19.08.14, 09:40

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

Формально, вы обобщили=подписались под первичным - матрица.

Цитата lamer2 @ 18.08.14, 18:23

Что правильнее сделать бызовым классом - вектор или матрицу?

С точки зрения науки, матрицы - операторы воздействующие на вектора=точки пространства. Ну а вначале были точки, а потом их уже начали отображать куда-то!..

Вы сейчас о математике или-таки об ООП?

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

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

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

Цитата Qraizer @ 19.08.14, 14:27

Вы сейчас о математике или-таки об ООП?

Ну... всё-таки программирование - следствие науки, в частности, математики.

Цитата Qraizer @ 18.08.14, 18:26

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

В этом мире все материальные сущности родственны - просто потому, что состоят
из элементарных частиц.
Что касается родственных связей объектов в конкретной программе то они зависят
от сознания программиста. Как ему удобнее, так и лучше.

Хорошо, Славян, второй вопрос: как связаны квадратное и кубическое уравнение? Нарисуй иерархию классов для их решения. *Добавь в иерархию уравнение 4-й степени. **И пятой.

Цитата Qraizer @ 19.08.14, 14:49

второй вопрос: как связаны квадратное и кубическое уравнение?

вначале было квадратное, а потом постарались решить кубическое и получилось. И понеслось. Иерархия тривиальна. А к чему сие?

Добавлено 19.08.14, 14:57

Цитата ЫукпШ @ 19.08.14, 14:46

Что касается родственных связей объектов в конкретной программе то они зависят
от сознания программиста. Как ему удобнее, так и лучше.

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

Ok, пофлудим.

Цитата Qraizer @ 18.08.14, 18:26

Ни то, ни другое.

Цитата D_KEY @ 18.08.14, 20:27

Зависит от того, что моделируем.

На что только люди не пойдут, чтобы не признавать, что на подобных задачах ООП фэйлится.

Цитата Славян @ 19.08.14, 14:54

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

Если он будет неправильно моделировать(а моделировать он должен то, что ему нужно с учетом того, что может понадобиться в дальнейшем), то попадет в еще более тяжелое положение.

Добавлено 19.08.14, 15:22

Цитата MyNameIsIgor @ 19.08.14, 15:05

На что только люди не пойдут, чтобы не признавать, что на подобных задачах ООП фэйлится.

А тут есть четкая постановка задачи?

Добавлено 19.08.14, 15:24

Цитата MyNameIsIgor @ 19.08.14, 15:05

пофлудим

ООП

Тогда стоит начать с определения ООП

Цитата D_KEY @ 19.08.14, 15:21

А тут есть четкая постановка задачи?

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

Цитата D_KEY @ 19.08.14, 15:21

Если он будет неправильно моделировать(...), то попадет в еще более тяжелое положение.

Не, давайте считать, что он всё делает правильно, а то так мы зарастём предположениями "если..то...".

Цитата D_KEY @ 19.08.14, 15:21

Тогда стоит начать с определения ООП

Оно не потребуется - такие задачи на раз троллятся принципом подстановки

Цитата Славян @ 19.08.14, 15:32

Цитата D_KEY @ 19.08.14, 15:21

Если он будет неправильно моделировать(...), то попадет в еще более тяжелое положение.

Не, давайте считать, что он всё делает правильно, а то так мы зарастём предположениями "если..то...".

Так в большинстве задач ему не потребуется моделировать именно полноценные концепции из математики. Если только это не его предметная область.

Добавлено 19.08.14, 15:43

Цитата MyNameIsIgor @ 19.08.14, 15:24

Цитата D_KEY @ 19.08.14, 15:21

А тут есть четкая постановка задачи?

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

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

Цитата D_KEY @ 19.08.14, 15:40

Так в большинстве задач ему не потребуется моделировать именно полноценные концепции из математики. Если только это не его предметная область.

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

Цитата D_KEY @ 19.08.14, 15:40

А если речь о математике, то я бы не наследовался.

Как не о математике, если очевидно, что речь идёт о сущностях именно из неё?

Цитата D_KEY @ 19.08.14, 15:40

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

Вот я и говорю - зафэйлилось ООП. Как и на классическом примере с множествами чисел.

Цитата Славян @ 19.08.14, 14:54

Иерархия тривиальна.

Ну так не составит труда реализовать и показать выгоды. Давай, я подожду решения до завтра. Не сильно мало времени? P.S. Решение тупо в процедурном стиле потребует примерно час.

Цитата Славян @ 19.08.14, 14:54

А к чему сие?

К тому, что не получится. Иерархия окажется костылём на костыле, и при этом не даст никакой выгоды.

Добавлено 19.08.14, 16:25

Цитата MyNameIsIgor @ 19.08.14, 15:05

На что только люди не пойдут, чтобы не признавать, что на подобных задачах ООП фэйлится.

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

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

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

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

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

К тому, что не получится. Иерархия окажется костылём на костыле, и при этом не даст никакой выгоды.

Частично согласен. Смотрите, это как с копированием может получиться:

if( n<16 ) goto Метод[n];
else ОбщийМетодКопирования();

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

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

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

А нет их в предметной области. Тоже самое и с матрицами и векторами.

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

Цитата 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, зависит от операций, которые ты определил для прямоугольника, квадрата и пр. Скажем, иммутабельный квадрат вполне себе иммутабельный прямоугольник

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

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

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

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

Добавлено 19.08.14, 18:11

Цитата BlackEmperor @ 19.08.14, 18:09

Все зависит от предметной области

В какой предметной области квадрат - не прямоугольник?

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

Цитата MyNameIsIgor @ 19.08.14, 18:11

Цитата BlackEmperor @ 19.08.14, 18:09

Все зависит от предметной области

В какой предметной области квадрат - не прямоугольник?

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

Цитата BlackEmperor @ 19.08.14, 18:13

Выше уже предлагалось сделать защищенное наследование квадрата от прямоугольника

А при чём тут я? Я такого не предлагал.

Цитата BlackEmperor @ 19.08.14, 18:13

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

Я куда-то не туда сморю... В сторону какой предметной области мне повернуться, чтобы увидеть?

Цитата MyNameIsIgor @ 19.08.14, 18:00

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

Отвечает. У меня безошибочные вычисления и все числа сводятся к целым и знак числа храниться отдельной переменной для простоты умножения.

Цитата BlackEmperor @ 19.08.14, 18:09

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

Так и я о том же.

Цитата Pavia @ 19.08.14, 18:19

Отвечает

Серьёзно? У вас комплексные - наследник действительных, я правильно понял? Как же тогда будет работать код, который не в курсе о мнимой части?

Добавлено 19.08.14, 18:21

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

Цитата BlackEmperor @ 19.08.14, 18:09

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

Так и я о том же.

Все знают эти особые предметные области, один я дурак

Цитата BlackEmperor @ 19.08.14, 18:13

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

Это в данном конкретном случае. В математике является. А в какой-то из ваших программ может. Почему нет?

Добавлено 19.08.14, 18:26

Цитата MyNameIsIgor @ 19.08.14, 18:21

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

Цитата BlackEmperor @ 19.08.14, 18:09

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

Так и я о том же.

Все знают эти особые предметные области, один я дурак

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

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

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

Но не называют эти предметные области.

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

а не то, что они знают конкретные хорошие примеры для синтетических случаев

Угу, теперь обвинения в искусственности, а всё ради священной коровы ООП

Цитата MyNameIsIgor @ 19.08.14, 18:28

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

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

Но не называют эти предметные области.

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

Цитата BlackEmperor @ 19.08.14, 18:32

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

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

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

Цитата MyNameIsIgor @ 19.08.14, 18:28

а всё ради священной коровы ООП

Мы тут про применимость и неприменимость наследования говорим, а ты почему-то это на ООП распространяешь. Если у меня квадраты от прямоугольников не наследуются, то у меня уже система ОО быть не может?

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

Мы тут про применимость и неприменимость наследования говорим, а ты почему-то это на ООП распространяешь

Так как бы без динамического субтипирования ООП быть не может

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

Если у меня квадраты от прямоугольников не наследуются, то у меня уже система ОО быть не может?

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

А вообще круто - ты перешёл от "это зависит от" к "почему не ООП?". Какая это стадия? Торг?

Цитата MyNameIsIgor @ 19.08.14, 18:28

Угу, теперь обвинения в искусственности

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

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

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

Да, можем делать разное. Но апологеты ООП говорят об одном его важном свойстве - расширяемости. Принцип подстановки при этом очень важен. Потому, заранее ограничивая твою систему только лишь потому, что твоё человеческое восприятие не совсем согласуется с тем, что диктует метод разработки, ты убиваешь самое важное свойство этого метода. Ну, и нафига он тебе?

Цитата MyNameIsIgor @ 19.08.14, 18:40

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

Мы тут про применимость и неприменимость наследования говорим, а ты почему-то это на ООП распространяешь

Так как бы без динамического субтипирования ООП быть не может

Я тебе сразу сказал, что нужно определение ООП

Цитата

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

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

Цитата

А вообще круто - ты перешёл от "это зависит от" к "почему не ООП?". Какая это стадия? Торг?

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

Добавлено 19.08.14, 18:50

Цитата MyNameIsIgor @ 19.08.14, 18:45

Ну, и нафига он тебе?

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

Сообщение отредактировано: D_KEY - 19.08.14, 18:50

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

Я тебе сразу сказал, что нужно определение ООП

Не, не нужно. Нужно иначе: если тебе известно определение ООП, которое допускает оное без субтипирования, то озвучь.

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

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

Так ты используешь личностные субъективные оценки. А я стараюсь говорить про объективное "является". И именно эти противоречия личностного и требуемого я и называю недостатком ООП в подобных случаях.
Как Pavia сказал - от простого к сложному. Люди так привыкли. Мы привыкли, что наследник сложнее предка. Обратное вызывает когнитивный диссонанс. Но оно именно так и есть

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

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

Забыть детали? Да ты в раю каком-то работаешь...

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

Цитата MyNameIsIgor @ 19.08.14, 18:58

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

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

Забыть детали? Да ты в раю каком-то работаешь...

А я не сказал, что у меня так Но у меня в разных проектах разная степень ОО-ти. И вот чем ее меньше, тем приходится больше вникать в детали. Такое вот субъективное наблюдение.

О, korvin, помогай! Они меня затравили

Цитата lamer2 @ 18.08.14, 18:23

Очевидно, что в ООП реализации жданных сущностей одно должно быть наследником другого.

Не очевидно.

Цитата lamer2 @ 18.08.14, 18:23

Матрица это вектор векторов.

Нет.

Цитата lamer2 @ 18.08.14, 18:23

С другой стороны вектор это матрица Nx1.

Нет.

Цитата lamer2 @ 18.08.14, 18:23

Что правильнее сделать бызовым классом - вектор или матрицу?

Qraizer всё правильно сказал:

Цитата Qraizer @ 18.08.14, 18:26

Ни то, ни другое. Если нечто выглядит похожим на что-то, это не значит, что они как-то должны быть связаны. Пример прям по горячему: матрица -- это вектор векторов; как сделать класс производным от самого себя?

Откуда пять страниц в теме? о_О'

korvin, ТТ, ты меня разочаровал

Цитата lamer2 @ 18.08.14, 18:32

Наследование определяется по правилу is A

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

Добавлено 19.08.14, 19:07

Цитата MyNameIsIgor @ 19.08.14, 19:05

ты меня разочаровал

Потому что не захоливарил? =))

Цитата korvin @ 19.08.14, 19:06

Потому что не захоливарил? =))

Потому что не пнул ООП. Давай про числа: наследуем действительные от комплексных или наоборот? Если не наследуем, то я утверждаю, что это не ООП, ибо не отразили отношение "является".

Цитата MyNameIsIgor @ 19.08.14, 19:08

Потому что не пнул ООП. Давай про числа: наследуем действительные от комплексных или наоборот? Если не наследуем, то я утверждаю, что это не ООП, ибо не отразили отношение "является".

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

Цитата MyNameIsIgor @ 19.08.14, 18:58

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

Я тебе сразу сказал, что нужно определение ООП

Не, не нужно. Нужно иначе: если тебе известно определение ООП, которое допускает оное без субтипирования, то озвучь.

ООП - метод программирования, основанный на концепции объектов и их взаимодействия без знания деталей о внутреннем устройстве друг друга

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

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

Ну так вперёд, реши кубическое уравнение с коэффициентом 0 при x³.

Цитата korvin @ 19.08.14, 19:12

В Схемке это все уживается без этих ваших ООП =)

Вот я и говорю - ООП в пролёте

Цитата D_KEY @ 19.08.14, 19:15

ООП - метод программирования, основанный на концепции объектов и их взаимодействия без знания деталей о внутреннем устройстве друг друга

Такое исчерпывающее определение... Что за "концепция объектов"? Что такое "объект"?

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

Ну так вперёд, реши кубическое уравнение с коэффициентом 0 при x3

Вот для частного случая и использую формулу решения квадратных уравнений.

Цитата D_KEY @ 19.08.14, 19:15

ООП - метод программирования, основанный на концепции объектов и их взаимодействия без знания деталей о внутреннем устройстве друг друга

Уговорил, STL - классический пример ООП.

Добавлено 19.08.14, 19:22

Цитата korvin @ 19.08.14, 19:12

А субтипирование и специальный полиморфизм (чтоб складывать комплексные с остальными) -- вещи ортогональные наследованию

Кстати, про субтипиторвание. Подтип - не обязательно наследник. Но ведь наследник - всегда подтип. Так почему ортогональны?

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

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

Погугли "перемножить векторы".

Добавлено 19.08.14, 19:25

Цитата MyNameIsIgor @ 19.08.14, 18:00

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

Нет. Чем выше мощность поля, тем меньше общности.

Цитата korvin @ 19.08.14, 19:16

Цитата D_KEY @ 19.08.14, 19:15

ООП - метод программирования, основанный на концепции объектов и их взаимодействия без знания деталей о внутреннем устройстве друг друга

Такое исчерпывающее определение... Что за "концепция объектов"? Что такое "объект"?

Зато очень общее Да несерьезно я.

Добавлено 19.08.14, 19:31

Цитата MyNameIsIgor @ 19.08.14, 19:20

Уговорил, STL - классический пример ООП.

Не классический, а подходящий по данному мною определению У автора STL определение ООП другое и в его голове STL не является примером ООП.

Цитата korvin @ 19.08.14, 19:06

Потому что не захоливарил? =))

Действительно, почему ты так нехорошо поступил? А, korvin?

Цитата MyNameIsIgor @ 19.08.14, 19:20

Но ведь наследник - всегда подтип.

Это несколько спорно. 1) Он может быть не подтипом, а тем же самым типом, когда класс != тип, как, например, в Ocaml; 2) Сильно зависит от того, что считать типом, наследник может нарушать контракты родителя в общем случае (редкий язык позволяет это строго ограничить), но даже с теми же числами: наследование используется для двух вещей: уточнение и расширение, если мы унаследуем комплексное от действительного с целью расширения, то сталкиваемя с проблемой: какой тип должен быть "ведущим" при "смешаном" сложении. Допустим у нас чистое ООП и сложение -- метод объекта, соответсвенно "ведущий" объект слева: если мы пишем "1 + 2+3i", каков должен быть результат? А при "1+2i + 3"? Это снова кидает нас в философствование.

Цитата Qraizer @ 19.08.14, 19:32

Действительно, почему ты так нехорошо поступил? А, korvin?

Вторник, поздний вечер, завтра на работу. Совсем не тот день. =)

Цитата korvin @ 19.08.14, 19:32

Он может быть не подтипом, а тем же самым типом, когда класс != тип, как, например, в Ocaml

Ok

Цитата korvin @ 19.08.14, 19:32

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

Не-не, IMHO котракты мы в типы не попрём

Цитата korvin @ 19.08.14, 19:32

но даже с теми же числами: наследование используется для двух вещей: уточнение и расширение, если мы унаследуем комплексное от действительного с целью расширения, то сталкиваемя с проблемой: какой тип должен быть "ведущим" при "смешаном" сложении. Допустим у нас чистое ООП и сложение -- метод объекта, соответсвенно "ведущий" объект слева: если мы пишем "1 + 2+3i", каков должен быть результат? А при "1+2i + 3"? Это снова кидает нас в философствование.

По-моему, подобное расширение ломает принцип подстановки и потому неприемлемо.

Цитата D_KEY @ 19.08.14, 19:02

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

Так это с модульностью, декомпозицией проблемы, при чем тут ООП?

Добавлено 20.08.14, 04:00

Цитата MyNameIsIgor @ 19.08.14, 19:59

По-моему, подобное расширение ломает принцип подстановки и потому неприемлемо.

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

Цитата korvin @ 20.08.14, 03:56

А если мы будем наследовать действительные от комплексных (уточнение), то придется тащить весь "комплексный багаж" в более простые типы

Да, но это будет правильнее.

Цитата korvin @ 20.08.14, 03:56

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

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

А вообще, я ведь и говорю - фэйлится ООП.

Цитата korvin @ 20.08.14, 03:56

Цитата D_KEY @ 19.08.14, 19:02

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

Так это с модульностью, декомпозицией проблемы, при чем тут ООП?

Ну вот при использовании ООП в плане "модульности и декомпозиции" все обычно гораздо лучше

Добавлено 20.08.14, 07:58

Цитата MyNameIsIgor @ 20.08.14, 06:42

я ведь и говорю - фэйлится ООП.

Почему фэйлится ООП, а не наследование реализации в данном конкретном случае?

Цитата D_KEY @ 20.08.14, 07:55

Почему фэйлится ООП, а не наследование реализации в данном конкретном случае?

По второму кругу пойдём? Ответ выше есть.

Цитата D_KEY @ 20.08.14, 07:55

Ну вот при использовании ООП в плане "модульности и декомпозиции" все обычно гораздо лучше

Может просто кто-то не умеет в "модульность и декомпозицию" отличным от ООП способом? =)

Цитата MyNameIsIgor @ 20.08.14, 08:02

Цитата D_KEY @ 20.08.14, 07:55

Почему фэйлится ООП, а не наследование реализации в данном конкретном случае?

По второму кругу пойдём? Ответ выше есть.

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

Добавлено 20.08.14, 08:09

Цитата korvin @ 20.08.14, 08:07

Цитата D_KEY @ 20.08.14, 07:55

Ну вот при использовании ООП в плане "модульности и декомпозиции" все обычно гораздо лучше

Может просто кто-то не умеет в "модульность и декомпозицию" отличным от ООП способом? =)

Может быть

Сообщение отредактировано: D_KEY - 20.08.14, 08:09

Цитата D_KEY @ 20.08.14, 08:08

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

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

Цитата MyNameIsIgor @ 20.08.14, 08:16

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

Допустим, что это так. Что ты предлагаешь?

Цитата D_KEY @ 20.08.14, 08:21

Допустим, что это так. Что ты предлагаешь?

Вместо ООП? Так я ничего не предлагаю, ибо не предлагаю отказываться от ООП. Я всего лишь сказал, что в некоторых примерах использовать ООП становится неудобно, оно мешает, а не помогает.

Цитата MyNameIsIgor @ 20.08.14, 08:24

оно мешает, а не помогает.

Чем тебе мешает отсутствие наследования, допустим, в случае квадрата и прямоугольника? И если оно мешает, то почему ты не сделаешь так, чтоб не мешало? Это пожалуй самый простой пример из темы и наследование там только в одну сторону возможно. Давай на нем и обсудим все как следует. Я вот, например, так и не понял твою мысль по поводу принципа подстановки.

Добавлено 20.08.14, 08:38
Вот, например, тип квадрата теоретически мог бы задаваться предикатом над прямоугольником(а тот в свою очередь предикатом над многоугольником и т.д.) Но я не уверен, что это будет хоть чем-то удобно на практике.

Цитата D_KEY @ 20.08.14, 08:33

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

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

Добавлено 20.08.14, 08:41

Цитата D_KEY @ 20.08.14, 08:33

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

Как этот предикат соотносится с системой типов языка?

Цитата MyNameIsIgor @ 20.08.14, 08:40

Цитата D_KEY @ 20.08.14, 08:33

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

Как этот предикат соотносится с системой типов языка?

Вроде scheme умеет создавать типы по предикатам. Тут нужен korvin

Добавлено 20.08.14, 08:48

Цитата MyNameIsIgor @ 20.08.14, 08:40

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

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

Цитата D_KEY @ 20.08.14, 08:43

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

На самом деле, не вижу подобных проблем, если мы можем переопределить все необходимые методы.

Цитата D_KEY @ 20.08.14, 08:43

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

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

Цитата MyNameIsIgor @ 20.08.14, 09:14

Цитата D_KEY @ 20.08.14, 08:43

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

На самом деле, не вижу подобных проблем, если мы можем переопределить все необходимые методы.

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

Цитата

Цитата D_KEY @ 20.08.14, 08:43

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

... но по твоим же словам являются таковыми в предметной области

Но для нашей модели предметной области это не существенно. Если существенно, нужно было так и проектировать.

Цитата

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

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

Цитата D_KEY @ 20.08.14, 08:43

Вроде scheme умеет создавать типы по предикатам.

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

#lang racket
 
(define/contract (natural? x) predicate/c
  (and (integer? x)
       (positive? x)))
 
(define/contract (natural+ x y) (natural? natural? . -> . natural?)
  (+ x y))
 
(displayln (natural+ 1 2))
(displayln (natural+ 1.2 3))

3
. . ..\..\Program Files\Racket\collects\racket\contract\private\blame.rkt:135:0: natural+: contract violation
  expected: natural?
  given: 1.2
  in: the 1st argument of
      (-> natural? natural? natural?)
  contract from: (function natural+)
  blaming: anonymous-module
  at: unsaved-editor2793:7.18
>

Другое дело, что в Racket можно создавать полноценно новые типы на основе существующих, что вряд ли есть хоть в каком-то динамически-типизированном языке, да и в статических не часто встречается.

Например:

complex.rkt:

#lang racket
 
(provide/contract
 #:exists complex
 (make-complex (-> number? number? complex))
 (real-part (-> complex number?))
 (imag-part (-> complex number?)))
 
(define (make-complex real imag)
  (cons real imag))
 
(define (real-part c)
  (car c))
 
(define (imag-part c)
  (cdr c))

test.rkt:

#lang racket
 
(require "complex.rkt")
  
(define c (make-complex 1 2))
(printf "~a+~ai\n" (real-part c) (imag-part c))
(printf "~a+~ai\n" (car c) (cdr c))

1+2i
. car: contract violation
  expected: pair?
  given: #<complex/∃>
>

Добавлено 20.08.14, 09:31

Цитата D_KEY @ 20.08.14, 09:29

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

А как же повторное использование? Как же библиотеки? Т.е. мы не можем (в ряде случаев) просто написать библиотеку классов, которая бы везде подходила?

Цитата korvin @ 20.08.14, 09:29

А как же повторное использование?

Ну так используй повторно, если оно тебе подходит. Проблема в чем?

Цитата

Т.е. мы не можем (в ряде случаев) просто написать библиотеку классов, которая бы везде подходила?

В ряде случаев не можем. И не только "классов". Ты где-то видел другое?

Квадратное равнение не является частным случаем кубического, поскольку в определении кубического уравнения особо оговорено, что коэфииент при x³ не равен нулю. Так же как в квадратном оговаривается, что не равен нулю коэффициент при x².