Ответ на »сообщение 4319« (Сергей Губанов)
___________________________


Gamma - это "утконос".
Изюминка в том, что сообщения образуют свою иерархию.

Alpha - обрабатывает несколько своих иерархий сообщений.

Beta - обрабатывает несколько своих иерархий сообщений.

Gamma - обрабатывает несколько своих иерархий сообщений + часть иерархий Alpha-сообщений + часть иерархий Beta-сообщений (в данном примере иерархий всего по одной, дабы не засорять...). То есть Gamma частично похожа на Alpha и частично похожа на Beta.


Сергей, идея нескольких иерархий сообщений интересна.
Но в предложенном Вами варианте Gamma уже не наследует ни Alpha, ни Beta, и, следовательно, не может быть подставлена вместо них.
(Если я не упустил что-нибудь из виду.)
Может быть, поступить несколько иначе -- оставить  один "родовой" обработчик, который будет  обрабатывать несколько "под-иерархий" сообщений?
Например:

TYPE
  Message = ABSTRACT RECORD END;
  AlphaMsg = ABSTRACT RECORD (Message) END;
  BetaMsg = ABSTRACT RECORD (Message) END;
  GammaMsg = ABSTRACT RECORD (Message) END;
  Object = POINTER TO ABSTRACT RECORD
    (me: Object) Handle (VAR msg: Message), NEW, EMPTY
  END;

Ответ на »сообщение 4318« (ASU)
___________________________


Да, приглашаю в... «Семантическое моделирование».


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

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


Здесь все просто, IMHO. Квадрат – частный случай прямоугольника, прямоугольник – частный случай четырехугольника...
«Второе значение» у квадрата не лишнее, оно просто равно «первому значению». То есть, можно спросить у прямоугольника: «Ты квадрат?», - и прямоугольник, сравнив width и height, ответит либо утвердительно, либо отрицательно. Надо ли вообще делать квадрат отдельным классом? Для решения каких задач, это необходимо?..

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

Ответ на »сообщение 4312« (AVC)
Утконос похож на большого крота и является млекопитающим.

Подобные задачи решаются примерно так:

DEFINITION SamplePolymorphism;

  IMPORT GenericBase, AlphaBase, BetaBase;

  TYPE
    Alpha = POINTER TO ABSTRACT RECORD (AlphaBase.Object)
      (this: Alpha) HandleAlphaMsg (VAR msg: AlphaMsg), NEW, EMPTY
    END;

    Beta = POINTER TO ABSTRACT RECORD (BetaBase.Object)
      (this: Beta) HandleBetaMsg (VAR msg: BetaMsg), NEW, EMPTY
    END;

    Gamma = POINTER TO ABSTRACT RECORD (GenericBase.Object)
      (this: Gamma) HandleAlphaMsg (VAR msg: AlphaMsg), NEW, EMPTY;
      (this: Gamma) HandleBetaMsg (VAR msg: BetaMsg), NEW, EMPTY;
      (this: Gamma) HandleGammaMsg (VAR msg: GammaMsg), NEW, EMPTY
    END;

    AlphaMsg = ABSTRACT RECORD END;

    BetaMsg = ABSTRACT RECORD END;

    GammaMsg = ABSTRACT RECORD END;

END SamplePolymorphism.

Gamma - это "утконос".
Изюминка в том, что сообщения образуют свою иерархию.

Alpha - обрабатывает несколько своих иерархий сообщений.

Beta - обрабатывает несколько своих иерархий сообщений.

Gamma - обрабатывает несколько своих иерархий сообщений + часть иерархий Alpha-сообщений + часть иерархий Beta-сообщений (в данном примере иерархий всего по одной, дабы не засорять...). То есть Gamma частично похожа на Alpha и частично похожа на Beta.

Ответ на »сообщение 4311« (AVC)
___________________________
Теперь Ваш образ мыслей стал мне немного понятнее.
IMHO, обсуждаемые вопросы шире не только обероновской тематики, но и программирования вообще (в смысле -- программирования только как программирования). Подобное впечатление у меня в свое время было при чтении книги Шлаер и Меллора.
Наверное, можно примерно определить эту область как "моделирование". (Например, упомянутая книга называлась "Object lifecycles: modeling the world in states".)
Согласен, что имеет смысл выделить это обсуждение (оно по прежнему представляет для меня интерес) в отдельную ветку.
Да, приглашаю в... «Семантическое моделирование».

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

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

Другое затруднение связано с пониманием отношения между наследованием и классификацией, точнее с попытками выразить классификацию через наследование.
По правилам логики, вид должен иметь меньший объем, чем род, но большее содержание (т.е. больше признаков).
Рассмотрим простой пример: квадрат есть прямоугольник с равными сторонами.
Казалось бы, что проще.
"Унаследуем" квадрат от прямоугольника и получим... ненужное поле в записи.

TYPE Rectangle = RECORD width, height: INTEGER END;

Но для квадрата второе значение -- лишнее, ведь заранее известно, что они совпадают.
В пору поступать наоборот -- наследовать прямоугольник от квадрата!
Наверное, это мелочь, но все же...
Здесь все просто, IMHO. Квадрат – частный случай прямоугольника, прямоугольник – частный случай четырехугольника...
«Второе значение» у квадрата не лишнее, оно просто равно «первому значению». То есть, можно спросить у прямоугольника: «Ты квадрат?», - и прямоугольник, сравнив width и height, ответит либо утвердительно, либо отрицательно. Надо ли вообще делать квадрат отдельным классом? Для решения каких задач, это необходимо?..

Ответ на »сообщение 4316« (AVC)
___________________________


Несомненно пока одно: для ООП необходим полиморфизм = ситуация, когда несколько классов имеют один тип.


Впрочем, в виртовском Обероне даже это необязательно. Метод (процедурную переменную в записи) можно переустановить "на лету", что также дает полиморфное поведение... без классов. (?)

Ответ на »сообщение 4315« (Takun)
___________________________


А нужна эта вообще классификация?
(А нужно ли вообще это наследование? А то некоторые предлагают обходится композицией)

Вот это я и хочу выяснить.
Пока что получается примерно следующее.
Полиморфизм - это когда несколько классов имеют один тип. Дополнительные отношения между классами (наследование реализации) для этого не требуются. Если же одному классу потребуется использовать реализацию другого, то наследование можно заменить делегированием.
Есть еще подтипы (расширения интерфейса). С ними тоже не так все ясно.
Пусть T0 -- некий базовый тип, а Т1 -- его (расширенный) подтип. Пусть также M0 -- модуль, в котором определен тип T0, а M1 -- модуль, в котором определен T1. Ясно, что M1 импортирует M0.
Там, где объект типа T1 замещает объект типа T0, он и используется просто как объект типа T0, т.к. Вы правильно отметили, что проверка типа в такой ситуации не поощряется (не считается нормой ООП).
Кроме того, зачастую такая проверка даже невозможна (по крайней мере, в Обероне). Например, в модуле M0, т.к. не M0 импортирует M1, а наоборот (и циклического импорта в Обероне нет).
Там же, где объект типа T1 используется именно в качестве объекта типа T1, зачастую не имеет значения, что T1 есть подтип T0.
Т.е. объект типа T1 ведет себя как T0 и T1 в разных контекстах. Поэтому не исключено, что и отношение тип-подтип тоже не обязательно, и его можно будет чем-то заменить...
Кроме того, расширить функциональность можно и без явного введения подтипа. Например, с помощью обероновских родовых интерфейсов.

В общем, не все ясно (или все не ясно :)).
Несомненно пока одно: для ООП необходим полиморфизм = ситуация, когда несколько классов имеют один тип.

Ответ на »сообщение 4311« (AVC)
___________________________

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


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

Вот и я зачастую попадаю в трудное положение д-ра Шау. :)

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

Другое затруднение связано с пониманием отношения между наследованием и классификацией, точнее с попытками выразить классификацию через наследование.
По правилам логики, вид должен иметь меньший объем, чем род, но большее содержание (т.е. больше признаков).
Рассмотрим простой пример: квадрат есть прямоугольник с равными сторонами.
Казалось бы, что проще.
"Унаследуем" квадрат от прямоугольника и получим... ненужное поле в записи.

TYPE Rectangle = RECORD width, height: INTEGER END;

Но для квадрата второе значение -- лишнее, ведь заранее известно, что они совпадают.
В пору поступать наоборот -- наследовать прямоугольник от квадрата!
Наверное, это мелочь, но все же...
Не совсем понятно, причем здесь классификация. Наследование (реализации) используется для повторного использования некой функциональности. Поведение квадрата можно выразить через поведение ромба, запретив устанавливать непропорциональный размер, в то время как код отрисовки квадрата бесполезен для отрисовки прямоугольника (вычисления его площади и т.п). Того же можно было бы достигнуть при помощи агрегации с переадресацией команд. Что касается наследования интерфейса, то здесь это скорее средство написания обобщенных алгоритмов (например расположить фигуры на экране в ряд), с точки зрения которых все объектны равноценны и имеют лишь некий набор общих свойств (координаты, размер прямоугольника, в который она вписана). Писать алгоритмы учитывающие тип объектов, которыми они манипулируют, в народе считается некультурным, так как такой код труднее поддерживать и расширять (? по крайне мере упомнания о проверки типов обычно провоцирует множество критических высказываний). Т.е. классификации как таковой тоже нет. В результате появляются такие языки как Self, в котором ни наследования интерфейса (как и во всех динамически типизируемых языках), ни наследования реализации, и при этом считается чистым оо языком. И Лимбо туда же, до кучи.
В качестве упражнения предлагаю продумать иерархию типов чисел: целых, рациональных, комплексных... (а заодно четных, простых и т.п.) :0)
Например в Смолтоке целые и рациональные наследуются от класса "величина", которых характеризует объекты, для которых определено отношение порядка (<, >, =), вот только комплексные числа в такую классификацию не укладываются...
А нужна эта вообще классификация?
(А нужно ли вообще это наследование? А то некоторые предлагают обходится композицией)

Ответ на »сообщение 4313« (sdf)
___________________________


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


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

Ответ на »сообщение 4312« (AVC)
___________________________

зачем же ходить так далеко, в область биологии и зоологии? возьмите нашу предметную область. классификатор acm - computing classification system: http://portal.acm.org/ccs.cfm?part=author&coll=GUIDE&dl=GUIDE&row=D.3&idx=4&CFID=61785746&CFTOKEN=68699549

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

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

Ответ на »сообщение 4311« (AVC)
___________________________

Хотел бы добавить пару слов к сказанному.
Заранее прошу прощения, если кому-либо из ревнителей Оберона (а это и мой любимый язык) это покажется оффтопиком. Ведь теперь на форуме, вдобавок к Лао-Цзы и соленым огурцам, еще и утконосы появятся. :)

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

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

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