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

[Xaositect]

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

А что такое здравый смысл?

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

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

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

Проблема в том, что реализация с модифицирующими методами в данном случае затруднительна.

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

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

Да, перепутал термин. Это называлось "обратное наследование" в той статье, что я читал. Понятно, что есть паттерны, без паттернов не обойтись в такой ситуации.

[kolas]

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

Здравый смысл в данном случае

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

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

[arseniiv]

Определите "метод формализации". Что вы под этим понимаете?

-- Чт дек 09, 2010 18:18:40 --

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

наследует логику

И вот это определите тоже.

[Joker_vD]

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

в принципе он наследует логику.

Т.е. кое-где он от логики отходит?

Xaositect
Кстати, к таким же выводам пришли и Дейт с Дарвеном (одни из ведущих теоретиков по реляционной модели данных), когда разбирались с тем, как объектно-реляционные БД соотносятся с чисто реляционными. В результате появилась такая вот статья по модели наследования: Towards an Agreeable Model of Type Inheritance (Названо "Type Inheritance" потому, что они предпочитают всегда явно различать типы, значения и переменные, что, на мой взгляд, стоит бы делать и апологетам ООП).

[Munin]

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

А пока в физике существуют титаны, которые и двигают ее в перед, а метода как такового нет.

Предлагаю данного участника забанить за лженауку.

[kolas]

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

Предлагаю данного участника забанить за лженауку.

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

Joker_vD в сообщении #385318 писал(а):

Т.е. кое-где он от логики отходит?

Это одна из реализаций логики.

Joker_vD в сообщении #385318 писал(а):

как объектно-реляционные БД соотносятся с чисто реляционными

Очень хорошо относятся и сейчас везде используются, так называемые ORM движки, типа hibernate, entity framework и куча других. Мы немного склонны думать что ооп это язык, платформа, программа, база данных и т.д. На самом деле это не так, ооп это метод, мы можем на любом языке спроектировать систему методами ооп, ооп применяется не только в компьютерных программах, но и при проектировании кораблей, машин, ракет, электроники и др. Один из примеров методов ооп - классификация типов в биологии.

arseniiv в сообщении #385309 писал(а):

Определите "метод формализации". Что вы под этим понимаете?

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

[Xaositect]

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

Joker_vD в сообщении #385318 писал(а):

как объектно-реляционные БД соотносятся с чисто реляционными

Очень хорошо относятся и сейчас везде используются, так называемые ORM движки, типа hibernate, entity framework и куча других. Мы немного склонны думать что ооп это язык, платформа, программа, база данных и т.д. На самом деле это не так, ооп это метод, мы можем на любом языке спроектировать систему методами ооп, ооп применяется не только в компьютерных программах, но и при проектировании кораблей, машин, ракет, электроники и др. Один из примеров методов ооп - классификация типов в биологии.

Вы статью-то прочитали? Она не про ORM (способ работы с реляционными базами с использованием ОО-парадигмы), она про ORD (системы баз данных с поддержкой объектов). И даже не про ORD, а про то, каким должна быть хорошая система типов для ORD. И Дэйт-Дарвен говорят, что принцип подстановки не должен выполняться для переменных (т.е. в случае изменения объектов, напр. присваивания и модифицирующих методов: мы можем изменить горизонтальную ось у эллипса, но не можем этого сделать у круга, несмотря на то, что он отнаследован.)

[kolas]

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

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

Это называется полиморфизмом.

[Xaositect]

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

Это называется полиморфизмом.

Нет, это не называется полиморфизмом. Полиморфизм - это когда мы можем делать одни и те же вещи, не оглядываясь на конкретные типы значений, с которыми мы работаем. А то, о чем я говорю - это как раз ограничение subtype polymorphism'а. Мы не можем растянуть круг вдоль оси $x$, если у нас нет возможности изменить тип его на эллипс. Надо создавать новый объект.

[kolas]

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

Нет, это не называется полиморфизмом. Полиморфизм - это когда мы можем делать одни и те же вещи, не оглядываясь на конкретные типы значений, с которыми мы работаем. А то, о чем я говорю - это как раз ограничение subtype polymorphism'а. Мы не можем растянуть круг вдоль оси $x$, если у нас нет возможности изменить тип его на эллипс. Надо создавать новый объект.

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

[Xaositect]

В этом-то вся проблема, что если нужно растянуть круг, а не увеличить, то его нужно кастить к эллипсу. То есть нужно в программе явно различать круг как круг и круг как эллипс. А это как раз отход от полиморфизма.
Т.е., наследование, соответствующие отношению "тип A есть подмножество типа B с некоторым ограничением на значения его полей" (в нашем случае полуоси эллипса равны), несовместимо с тем, что мы можем менять поля независимо.

[Joker_vD]

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

Это одна из реализаций логики.

Я, увы, матлогику строго не изучал, поэтому не знаю — может, "реализация логики" и не является бессмысленным словосочетанием...

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

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

То есть мы-таки сможем сделать некруглый круг. Здорово, правда? Вот только в унаследованном круге нету ни сеттера высоты, ни сеттера длины, только сеттер радиуса. Это идея — по умолчанию сеттеры не наследуются — в статье выражена не очень ярко.

Разумеется, такая модель не отменяет возможность использовать существующую сейчас модель расширения типов (type extending), когда расширение всего лишь добавляет новые аттрибуты в существующее представление, не удаляя никаких из старых.

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

В этом-то вся проблема, что если нужно растянуть круг, а не увеличить, то его нужно кастить к эллипсу. То есть нужно в программе явно различать круг как круг и круг как эллипс. А это как раз отход от полиморфизма.

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

[Xaositect]

Joker_vD в сообщении #385689 писал(а):

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

Вот и я о том же. И Дэйт с Дарвеном то же самое говорят. Надо либо разрешить кругу превращаться в эллипс в runtime, либо не наследовать такие операции.

-- Пт дек 10, 2010 13:25:36 --

Joker_vD в сообщении #385689 писал(а):

Я, увы, матлогику строго не изучал, поэтому не знаю — может, "реализация логики" и не является бессмысленным словосочетанием...

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

[kolas]

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

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

А в чем проблема? Если мы растянем круг, он перестанет быть кругом, и это явно нужно описать, никакой магии.

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

тип A есть подмножество типа B с некоторым ограничением на значения его полей

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

Joker_vD в сообщении #385689 писал(а):

То есть мы-таки сможем сделать некруглый круг. Здорово, правда? Вот только в унаследованном круге нету ни сеттера высоты, ни сеттера длины, только сеттер радиуса.

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

[Xaositect]

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

А в чем проблема? Если мы растянем круг, он перестанет быть кругом, и это явно нужно описать, никакой магии.

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

-- Пт дек 10, 2010 13:39:55 --

Это конкретная проблема, связанная с конкретным видом наследования, который я описал: "тип A есть подмножество типа B с некоторым ограничением на значения его полей". В других случаях все может быть хорошо.