Объектно-ориентированная СУБД (прототип)
ъектов
. Клонирование объектов
. Переопределение поведений и действий
. Изменение данных в объектах
. Журнализация изменений в объектах
. Выполнение действий (knowhow)
2. Уточнение методов решения задачи
2.1 Наследование
Наследование является мощным средством моделирования (поскольку кратко
и точно описывает мир) и помогает программисту разрабатывать новые версии
классов и методов, не опасаясь повредить работающую систему. Наследование
способствует повторному использованию кода, потому что каждая программа
находится на том уровне, на котором ее может использовать наибольшее число
объектов.
Совокупности свойств объекта в объектно-ориентированной базе данных
уделяется большее внимание, чем во многих объектно-ориентированных языках
программирования, поскольку они являются также целью запросов.
Объект=состояние+поведение. Чаще всего существует только одна иерархия
наследования. Этот подход перешел и в C++. Однако, возможно разделение
иерархий наследования данных и наследования поведений. Не всегда желательно
иметь точно такую же иерархию наследования поведения, как и иерархию
наследования свойств. Разделение этих двух иерархий повышает возможности
переиспользования (reuse) поведений.
Значение переиспользования поведений
Предположим, мы имеем класс Студент и хотим создать класс Аспирант.
Чтобы стать аспирантом, человек должен сначала получить высшее образование
как студент. В общем случае экземпляры этих классов различны. Мы не можем
наследовать Аспирант от Студент, т.к. аспирант не является студентом. В
противном случае, мы имели бы право рассматривать аспиранта как экземпляр
класса Аспирант и, с тем же правом, как экземпляр класса студент. Тем не
менее, оба класса обладают общими атрибутами, такими как: имя, адрес,
номер_личной_карточки, а также большинством общих поведений. Это
обстоятельство побуждает создать класс Аспирант, унаследовав свойства и
поведения Студента. Однако, хотя экземпляры класса Аспирант будут
подмножеством всех экземпляров класса Студент (т.к. все аспиранты были
студентами, но не все студенты стали аспирантами), это представление будет
некорректно с точки зрения моделирования ситуации в реальном мире.
На рисунке представлено дерево наследования:
[pic]
Рис. 2: Диаграмма наследования
Свойства классов Студент и Аспирант наследуются от класса Учащийся.
Поведение класса Аспирант наследуется от Студент. Обычно подкласс
наследует все атрибуты и методы из суперклассов. В приложении к
наследованию поведений это означает, что класс-ученик (demandclass) состоит
в отношении Переиспользовать-от (Reuse-Of) с другим классом, называемым
классом-учителем (supplyclass), и класс-ученик должен наследовать все
поведения от класса-учителя.
Эталоны наследования: классы или прототипы?
В системе отсутствуют классы и типы. Роль класса может брать на себя
любой объект, называемый объектом-образцом. Такой вид наследования
называется наследованием на основе прототипов.
Как правило, системы с наследованием на основе прототипов
концептуально более просты по сравнению с системами на основе классов.
Порождение экземпляра достигается копированием объекта-образца. Копия
получает от системы уникальный идентификатор, отличный от идентификатора
любого другого объекта в системе.
Независимо от модели наследования (классы или прототипы) существует
две различные стратегии реализации механизма наследования: делегирование и
конкатенация.
Способ наследования: делегирование или конкатенация?
Делегирование представляет собой такую форму наследования, в которой
объединение интерфейсов реализовано посредством разделения родительских
интерфейсов, т.е. с использованием ссылок. Конкатенация достигает
аналогичного эффекта посредством копирования родительских интерфейсов в
интерфейс порождаемого класса или объекта, – как результат, полученный
интерфейс является непрерывным. В любом случае дочерний объект способен
отвечать как на сообщения, определенные в родительских интерфейсах, так и
на сообщения, добавленные к интерфейсу объекта. При делегировании те
сообщения, которые не могут быть обработаны объектом, должны быть
направлены родителям. При конкатенации каждый объект является
самодостаточным, и необходимость перенаправления сообщений отсутствует.
Введение идентификаторов полей позволяет распространить подходы
делегирования и конкатенации и на агрегатные объекты.
И конкатенация, и делегирование имеют свои достоинства и недостатки.
Делегирование обеспечивает возможность гибкого распространения изменений:
любое изменение свойств родителя автоматически отражается на потомках.
Подход, использующий конкатенацию, допускает изменение свойств родителей и
потомков независимо друг от друга, что также может быть полезно во многих
ситуациях. Делегирование обычно требует меньших затрат по памяти, в то
время как конкатенация является более эффективной по времени. Simula и C++
являются примерами языков, которые реализуют наследование на основе классов
с использованием делегирования. В Smalltalk реализовано наследование на
основе прототипов с использованием делегирования.
Обоснование избранного механизма наследования
Было решено использовать в дипломной работе механизм наследования на
основе прототипов с использованием конкатенации, как для состояний, так и
для поведений, поскольку для СУБД критично именно время выполнения
операций. Разделение наследований состояния и поведения позволяет уменьшить
объем хранимой в каждом объекте информации. В объект помещается ссылка на
объект, хранящий его интерфейс (т.е. поведение). Таким образом, интерфейсы
многих объектов с одинаковым поведением могут быть сосредоточены в одном
месте. Наследование на основе прототипов позволяет управлять конфигурацией
объектов-образцов и обеспечивает единство представления данных. Т.е.
результатом запроса к базе данных может быть список используемых методов,
их аргументы и другая информация, которая в системе с наследованием на
основе классов скрыта в классах. Создание экземпляра через копирование
снимает необходимость введения конструктора по умолчанию, поскольку
содержимое копируемого объекта и задает начальные значения.
Система поддерживает множественное наследование. Необходимость
множественного наследования остается предметом горячих споров. Практика
говорит о том, что «множественное наследование играет роль парашюта: в нем
нет постоянной необходимости, но если он вдруг понадобился, то большое
счастье иметь его под рукой» [8].
Определение родства
Остается важный вопрос: как определить, является ли объект потомком
другого объекта? Разделение наследований состояния и поведения приводит к
тому, что слово «потомок объекта» обретает двойственное значение. С одной
стороны, это потомок по данным, с другой стороны, это потомок по поведению.
На самом деле, в чистой объектно-ориентированной системе данные
объектов надежно защищены от вмешательства пользователя через механизм
инкапсуляции. Доступ к данным производится через методы. Таким образом,
родство объектов следует определять исключительно через их интерфейсы. В
системе на основе классов обычно строится дерево наследования. В системе
на основе прототипов с конкатенацией определение родства достигается за
счет операций пересечения интерфейсов. Поведение объекта составляют методы,
хранящиеся в объекте-множестве, а значит для определения родства необходимо
выполнить операцию пересечения множеств. Если получившийся в результате
пересечения интерфейс совпадает с интерфейсом одного из двух сравниваемых
объектов, то другой объект – его потомок. Фактически, это алгоритм
определения общего предка двух объектов. Использование множеств для
хранения интерфейсов позволяет взглянуть на операцию наследования
конкатенацией как на операцию слияния множеств.
2.2 Инкапсуляция
Идея инкапсуляции в языках программирования происходит от абстрактных
типов данных. С этой точки зрения объект делится на интерфейсную часть и
реализационную часть. Интерфейсная часть является спецификацией набора
допустимых над объектом операций. Только эта часть объекта видима.
Реализационная часть состоит из части данных (состояние объекта) и
процедурной части (реализация операций).
Интерпретация этого принципа для баз данных состоит в том, что объект
инкапсулирует и программу и данные.
Рассмотрим, например, объект Служащий. В реляционной системе служащий
представляется кортежем. Запрос к нему осуществляется с помощью
реляционного языка, а прикладной программист пишет программы для изменения
этой записи, например повышение зарплаты служащего или прием на работу.
Такие программы обычно пишутся либо на императивном языке программирования
с включением в него операторов языка манипулирования данными или на языке
четвертого поколения и хранятся в обычной файловой системе, а не в базе
данных. Таким образом, при таком подходе имеются кардинальные различия
между программой и данными, а также между языком запросов (для
незапланированных запросов) и языком программирования (для прикладных
программ).
В объектно-ориентированной системе служащий определяется как объ
| |  скачать работу |
Объектно-ориентированная СУБД (прототип) |
