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

Цитата 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

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

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