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

Упражнения

19.1. Дайте определение следующим терминам.

заменимость полиморфизм

корневой тип связывание во время выполнения

листовой тип сигнатура

непосредственный подтип скалярный тип

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

обобщение по ограничениям специализация по ограничениям

повторное использование кода фиктивный тип

19.2. Объясните действие оператора TREAT DOWN.

19.3. Каковы отличия между следующими понятиями.

19.4. Используя иерархию типов, изображенную на рис. 19.1, рассмотрите значение е, которое имеет тип ELLIPSE. Каков конкретный тип е - ELLIPSE или CIRCLE? Каков наименее конкретный тип е?

19.5. Любая заданная иерархия типов включает несколько подыерархий, каждая из которых может рассматриваться как отдельная иерархия типов. Например, иерархия типов, получаемая на рис. 19.1 посредством удаления типов PLANE FIGURE, ELLIPSE и CIRCLE (только), может считаться независимой. То же самое можно сказать об иерархии, получаемой посредством удаления типов CIRCLE, SQUARE и RECTANGLE (только). С другой стороны, иерархия, полученная посредством удаления типа ELLIPSE (только), не может считаться единой иерархией типов (по крайней мере, не может считаться иерархией, производной от иерархии, которая показана на рис. 19.1), поскольку тип CIRCLE выпал из цепочки наследования, если судить по исходной иерархии. Вопрос: Сколько различных иерархий типов (в указанном смысле) присутствует на рис. 19.1? .

19.6. Используя синтаксис, кратко изложенный в этой главе, дайте определения типов RECTANGLE (Прямоугольник) и SQUARE (Квадрат) (для простоты считайте, что все прямоугольники имеют центр в начале координат, но их стороны необязательно

>i расположены только вертикально или горизонтально).

19.7. Давая ответ к упр. 19.6, определите оператор поворота указанного прямоугольника на 90° вокруг его центра. Также представьте явную специализацию этого оператора для квадратов.

19.8. Повторим формулировку примера из раздела 19.6: Пусть переменная-отношение R имеет атрибут А объявленного типа ELLIPSE и требуется выбрать из нее такие кортежи, в которых значение атрибута А в действительности является окружностью с радиусом, большим 2 . Для данного запроса в разделе 19.6 была дана следующая формулировка.

R : IS CIRCLE ( А ) WHERE THE R ( А ) > LENGTH ( 2.0 )

а) Почему нельзя просто поместить выражение проверки типа в предложение WHERE, например так, как показано ниже?

R WHERE IS CIRCLE ( А ) AND THE R ( А ) > LENGTH ( 2.0 )

б) Вот еше один пример возможной формулировки запроса.

R WHERE CASE

WHEN IS CIRCLE ( A ) THEN

THE R ( A ) { TREAT DOWN AS CIRCLE ( A ) )

> LENGTH ( 2.0 ) WHEN NOT { IS CIRCLE ( A ) ) THEN FALSE END CASE

Верна ли эта формулировка? Если нет, то почему?

19.9. В [3.3] предлагается поддержка реляционных выражений следующего вида. R TREAT DOWN AS T ( А )

Здесь R - реляционное выражение, А - атрибут отношения (скажем, г), обозначаемый этим выражением, и Т - некоторый тип. Объявленный тип DT(A) атрибута А должен быть супертипом типа Т (проверка типа во время компиляции). Значение всего выражения определяется как отношение со следующими свойствами.

а) Его заголовок такой же, как заголовок отношения г, но тип атрибута А в нем - Т.

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

Напомним, что приведенный оператор TREAT DOWN является просто сокращением. Но сокращением чего именно?

19.10. Выражение вида R: IS T(A) также является сокращением. Сокращением чего именно?

Список литературы

19.1. Atkinson М.Р. et al. The Object-Oriented Database System Manifesto Proc. First International Conference on Deductive and Object-Oriented Databases. - Kyoto, Japan, 1989. New York, N.Y.: Elsevier Science. - 1990.

Относительно отсутствия согласия (как уже отмечалось в разделе 19.1) по вопросу, что должна собой представлять настоящая модель наследования, авторы настоящей статьи высказываются так: Имеется по крайней мере четыре типа наследования: наследование заменимости, включаемое наследование, наследование ограни-

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

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

В [19.4] Кливленд (Cleaveland) пищет: [Наследование может] основываться на [множестве] различных критериев, и не существует какого-либо общепринятого стандартного определения . Он также предлагает восемь возможных интерпретаций. (Мейер в [19.8] дает двенадцать.)

Баклавски (Baclawski) и Индурхия (Indurkhya) в [19.2] пищут: Язык программирования [просто] предоставляет множество механизмов [наследования]. Пока эти механизмы, безусловно, ограничивают и возможности языка, и возможные представления наследования... они не допускают для самих себя некоторые представления наследования. Классы, специализации, обобщения и наследование- это только понятия, и... они не имеют всеобщего объективного значения... Отсюда следует, что то, как наследование будет включено в конкретную систему, зависит от проектировщиков [данной] системы; именно это составляет стратегию разработки, которая должна быть реализована с помощью доступных механизмов . Другими словами, нет никакой модели!

19.2. Baclawski К., Indurkhya В. Technical Correspondence CACM. - September, 1994. -37, №9.

19.3. Cardelli L., Wegner P. On Understanding Types, Data Abstraction, and Polymoфhism ACM Сотр. Surv. - December, 1985. - 17, № 4.

19.4. Cleaveland G.J. An Introduction to Data Types. - Reading, Mass.: Addison-Wesley, 1986.

19.5. Date C.J. Серия статей по наследованию типов на Web-узле DBP feD www.dbpd.com. - 1999.

Статьи публиковались с февраля 1999 года. Это расширенная учебная разработка (с историческими примечаниями) модели наследования, описанной в настоящей главе и определенной более формально в [3.3].

19.6. Date C.J., Darwen Н. Toward а Model of Type Inheritance CACM. - December, 1998. -41, № 12.

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

19.7. Mattos N., DeMichiel L.G. Recent Design Trade-Offs in SQL3 ACM SIGMOD.- December, 1994. - Record 23, № 4.

В статье обосновывается решение разработчиков не поддерживать в SQL3 ограничения типа (это обоснование базируется на аргументе, который был выдвинут ранее Здоником (Zdonik) и Мейером (Maier) в [19.11]). Однако мы не согласны с таким обоснованием. Фундаментальная проблема заключается в том, что в нем неверно различаются значения и переменные (см. упр. 19.3).

19.3. Meyer В. The Many Faces of Inheritance: A Taxonomy of Taxonomy IEEE Computer. - May, 1996. - 29, № 5.

19.9. Rumbauch J, A Matter of Intent: How to Define Subclasses Journal of Object-Oriented Programming. - September, 1996.