Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
1999 г

Дорогие друзья!

Поздравляю вас с приятным событием: снова открыт свободный доступ к Web-сайту онлайнового журнала Database Programming & Design (www.dbpd.com). За то время, пока я не имел доступа к этому сайту, Кристофер Дейт успел опубликовать три заметки, которые базируются на его (совместно с Хью Дарвеном) прошлогодней книге "Основания объектно-реляционных баз данных: третий манифест". Поскольку в февральском выпуске DBPG Дейт начал новую серию, посвященную наследованию типов, я прежде всего предлагаю вашему вниманию именно февральскую заметку. Постараюсь представить пересказы и двух предыдущих.

Хочу обратить ваше внимание, что подход Дейта и Дарвена интересен, но не бесспорен. Когда я читал их книгу, временами у меня просто чесались руки написать свою статью с критикой некоторых идей. Наверное, я это действительно сделаю, но сначала давайте дадим полностью высказаться Дейту. Кстати, эта первая заметка сама по себе полезна для всех людей, которые еще не составили собственного представления о типах данных. Желаю вам интересного чтения и всяческих успехов.

До скорой встречи, Сергей Кузнецов


Intelligent Enterprise's

Database Programming & Design OnLine
February 1999

According to Date

Subtypes and Supertypes: Setting the Scene

(http://www.dbpd.com/vault/9902/date9902.shtml)

Закладывая основу нашего исследования наследования типов
Почему наследование типов?
Предварительные замечания
Что имеется в виду, когда мы говорим "тип"?
Все значения типизированы
Типизированы и все переменные
Простое и множественное наследование
Скаляры, кортежи и отношения
Структурное и поведенческое наследование
Подтаблицы и супертаблицы
Литература

Закладывая основу нашего исследования наследования типов

В этом месяце мы начинаем еще одну минисерию статей, которая посвящается понятиям подтипов, супертипов и наследования типов. Как я упоминал в своей заметке в ноябре 1998 г., эта тема оказалась удивительно сложной -- несмотря на тот факт, что основная идея очень проста. (Как это часто случается, черт скрывается в деталях.) Основную идею можно пояснить с помощью примера. Предположим, что имеются два типа ELLIPSE (эллипс) и CIRCLE (окружность) с очевидным смыслом. Тогда можно сказать, что тип CIRCLE является подтипом типа ELLIPSE (эквивалентно, тип ELLIPSE является супертипом типа CIRCLE), что понимается следующим образом:

  • Каждая окружность является эллипсом, но обратное неверно. (Некоторые эллипсы не являются окружностями.)
  • Следовательно, любая операция, применимая к эллипсам, вообще говоря, применима и к окружностям (поскольку окружности являются эллипсами), но обратное неверно. Например, операция THE_CTR (центр) применима к эллипсам и тем самым к окружностям, но операция THE_R (радиус) применима только к окружностям.
  • Более того, ограничение типа, применимое к эллипсам, вообще говоря, применимо и к окружностям (снова потому, что окружности являются эллипсами), но обратное неверно. Например, если к эллипсу применимо ограничение a >= b (где a и b - большая и меньшая полуоси эллипса соответственно), то окружности должны удовлетворять тому же ограничению. Конечно, для окружностей a и b совпадают с радиусом r, и это ограничение удовлетворяется тривиально; в действительности, к окружностям, но не ко всем эллипсам, в точности применимо ограничение a = b.

Таким образом, тип CIRCLE наследует операции и ограничения от типа ELLIPSE (свободно выражаясь), но имеет также собственные операции и ограничения, не применимые к типу ELLIPSE. Замечание: Здесь и во всей этой серии я буду использовать неуточненный термин "ограничение" в конкретном смысле ограничения типа, а в противном случае явно оговаривать другой смысл. Чтобы напомнить, ограничение типа (называемое также ограничением домена) - специфицирует просто допустимые значения данного типа.

Кстати, в этом месте новички иногда впадают в заблуждение: а именно, подтип обладает подмножеством значений, но супермножеством свойств. (Я использую термин "свойства" в качестве удобного сокращения для "операций и ограничений".) Например, тип CIRCLE содержит подмножество значений типа ELLIPSE, но индивидуальная окружность обладает всеми свойствами эллипса, а также и другими.

Почему наследование типов?

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

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

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

Однако, несмотря на потенциальные преимущества, все еще ощущается небольшое согласие относительно формальной, строгой и абстрактной модели наследования типов -- хотя существуют языки и продукты, в которых поддерживается некоторая разновидность наследования типов (и уже в течение некоторого времени) и в течение многих лет в книгах, статьях и презентациях обсуждается наследование типов. Цитируя Эндрю Тайвалсаари (Andrew Taivalsaari), "Основная идея наследования весьма проста … [несмотря на] ее центральную роль в современных … системах, наследование все еще представляет собой противоречивый механизм … [Какое-либо] исчерпывающее представление о наследовании все еще отсутствует."

Вот еще несколько цитат, иллюстрирующих тот же самый общий аспект:

  • Малькольм Аткинсон (Malcolm Atkinson) и др.: "Имеется по крайней мере четыре типа наследования: наследование подстановкой, наследование включением, наследование ограничением и наследование специализацией…В разной степени эти четыре типа наследования обеспечиваются в существующих системах и прототипах, и мы не предписываем конкретный стиль наследования." [2]
  • Дж. Крейг Кливленд говорит, что "[наследование может] основываться на [множестве] различных критериев, и отсутствует общепринятое стандартное определение" [3], и он переходит к изложению восьми различных интерпретаций. (Бертран Мейер [Bertrand Meyer] приводит 12 интерпретаций [4].)
  • Кеннет Баклавски (Kennet Baclavski) и Бипин Индуркхиа (Bipin Indurkhia) говорят: "Язык программирования [всего лишь] обеспечивает набор механизмов [наследования]. Хотя эти механизмы ограничивают возможные действия в этом языке и то, какие представления о наследовании могут быть реализованы … они сами по себе не узаконивают то или иное представление о наследовании. Классы, специализации, обобщения и наследования - это всего лишь концепции и … они не обладают универсальным объективным смыслом … Из этого [факта] следует, что способ внедрения наследования в конкретную систему возлагается на разработчиков [этой] системы, и это является политическим решением, реализуемым на основе доступных механизмов." [5] Другими словами, просто отсутствует модель!

Другие люди предлагают модели наследования, которые обладают противоречивыми, неинтуитивными и другими нежелательными свойствами. Например, текущие предложения SQL3 допускают такие вещи, как "неквадратные квадраты" [6] (т.е. значения типа SQUARE, стороны которого имеют разную длину) -- с тем результатом, что SQL3 трудно считать "хорошей моделью реальности". В действительности SQL3 даже не дает возможности устанавливать ограничения типа (вроде того, что у значений типа SQUARE стороны должны иметь одинаковую длину), не позволяет поддерживать их без посторонней помощи -- это, безусловно, неудовлетворительное положение дел. Что еще хуже, SQL3 не дает возможности устанавливать и поддерживать такие ограничения даже при отсутствии поддержки наследования, вероятно, при том предположении, что такая поддержка появится когда-то в будущем.

Однако в нашей книги The Third Manifesto мы с Хью Дарвеном предлагаем модель наследования, которая, как мы полагаем, является хорошей "моделью реальности" и не страдает такими недостатками [7]. Конечно, данная серия основывается на этой модели; по существу, она представляет собой легкое введение (не слишком глубокое) в наиболее важные идеи этой модели. Поэтому позвольте мне немедленно со стыдом сознаться, что одной из моих целей является реклама. Мы хотели бы, чтобы большая индустрия обратила серьезное внимание на наши идеи, потому что мы полагаем, что они могли бы служить основанием общепринятой модели, отсутствие которой так остро ощущается в настоящее время.

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

Предварительные замечания

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

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

Что имеется в виду, когда мы говорим "тип"?

Выражаясь нестрого, тип - это именованное множество значений (т.е. все возможные значения данного типа) вместе с ассоциированным набором операций, которые можно применять к этим значениям. Например, тип SMALLINT мог бы состоять из всех целых чисел в диапазоне от -32,768 до +32,767, а ассоциированным набором операций могли бы быть "+", "-", "*", "=", "<" и т.д. В более общей постановке я полагаю, что элементы следующего списка представляют собой аспекты концепции типа:

  • Данный тип может быть определенным либо системой, либо пользователем.
  • Часть определения любого типа представляет собой спецификацию всех возможных значений этого типа.
  • Такие значения могут быть произвольно сложными.
  • Реальное или физическое представление таких значений всегда скрывается от пользователя.
  • Такими значениями можно оперировать только посредством операций, определенных для данного типа.
  • В состав этих операций входит операция selector, которая позволяет "выбрать" -- или специфицировать -- произвольное значение данного типа (посредством соответствующего вызова селектора), и операция equality, которая дает возможность проверить, являются ли два значения данного типа на самом деле одним значением.
  • Некоторые типы являются подтипами других супертипов.
  • Если B - подтип A, то все операции и ограничения, применимые к A, применимы и к B (наследование); однако B может иметь свои собственные операции и ограничения, не применимые к A.

Заметим, что в реляционном мире типы обычно называются "доменами"; в объектном мире они обычно называются "классами". В этой серии я буду использовать термин "тип" (большей частью).

Все значения типизированы

Можно представлять, что с каждым значением связано что-то вроде флага, на котором написано "я целое", "я номер служащего", "я точка", "я эллипс" или что-то еще. При отсутствии наследования у каждого значения в точности один тип. Однако при наличии наследования значение может одновременно относиться к нескольким типам; например, данное значение в одно и то же время может относиться к типам CIRCLE и ELLIPSE.

Типизированы и все переменные.

Каждая переменная объявляется как переменная в точности одного типа. В языке Tutorial D, например, мы могли бы объявлять переменные следующим образом:

VAR E ELLIPSE ;

Здесь объявленным типом переменной E является ELLIPSE. При отсутствии наследования все возможные значения данной переменной относятся в точности к одному типу, а именно, к соответствующему объявленному типу. Однако при наличии наследования данная переменная может иметь значение, которое одновременно относится к нескольким типам; например, текущее значение переменной E может быть эллипсом, который на самом деле является окружностью, и, следовательно, в одно и то же время относится и к типу ELLIPSE, и к типу CIRCLE.

Простое и множественное наследование

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

Скаляры, кортежи и отношения

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

Структурное и поведенческое наследование

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

Подтаблицы и супертаблицы

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

Пример подтаблицы/супертаблицы

Рис. 1. Пример подтаблицы/супертаблицы

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

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

Литература

  1. Taivalsaari, Andrew. "On the Notion of Inheritance", ACM Comp. Surv. 28, No. 3. September 1996.
  2. Atkinson, Malkolm et al. "The Object-Oriented Database System Manifesto", Proceedings: First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan, 1989. Elsevier Science, 1990.
  3. J. Craig Cleaveland. An Introduction to Data Types. Addison-Wesley, 1986.
  4. Meyer, Bertrand. "The Many Faces of Inheritance: A Taxonomy of Taxonomy", IEEE Computer 29, No. 5. May 1996.
  5. Baclavski, Kenneth and Bipin Indurhya. Technical Correspondence, CACM 37, No. 9. September, 1994.
  6. International Organization for Standardization. Database Language SQL - Part 2: SQL/Foundation (Committee Draft). SQL3 Committee Drafts can be found on the World Wide Web at ftp://jarry.ece.umassd.edu/isowg3/dbl/BASEdocs/public.
  7. Date, C.J. and Hugh Darven. Foundation for Object/Relational Databases: The Third Manifesto. Addison-Wesley, 1998.

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
Apple запустила Pay Cash (2)
Четверг 09.11, 21:15
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...