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

Вид материала

Документы

Содержание Объектно-ориентированные базы данных Преимущества объектно-ориентированного подхода Таблица 11.1 (окончание) 11.2. История развития объектно-ориентированного подхода 11.3. Общие принципы объектно-ориентированного подхода 11.3.1. Объекты: компоненты и свойства 11.3.2. Идентификация объекта 11.3.3. Атрибуты (переменные экземпляра) Ocial_security_number 414-48-0944 On212;acct212;cis220;eng202;math301;hist20 2;cis310;acct343;acct345;eng242;mktg301;fi n331;acct355 11.3.8. Суперклассы, подклассы и наследование Наследование (inheritance) Единичное наследование 11.3.9. Переопределение методов и полиморфизм

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

Объектно-ориентированные базы данных

В этой главе мы будем изучать:

• основные концепции объектно-ориентированных систем (ОО-систем);
  
• влияние объектно-ориентированных концепций (ОО-концепций) на моделиро­вание данных и проектирование БД;
  
• использование объектно-ориентированных свойств в реляционных схемах и ER-
  

моделях;

• основные свойства системы управления объектно-ориентированной базой дан­ных (ООСУБД);
  
• достоинства и недостатки ООСУБД.
  

Обзор

Управление данными и разработка приложений стали гораздо сложнее, чем могли себе это представить создатели первых иерархических, сетевых и реляционных СУБД. Современные базы данных могут обрабатывать сложные данные как на уров­не управления данными, так и на уровне разработки приложений (последняя воз­можность появилась сравнительно недавно). В конце 1980-х — начале 1990-х годов требования к информации настолько усложнились, что данные стало очень трудно обрабатывать с помощью существующих технологий баз данных. Изменившийся состав данных, которые необходимо было моделировать (графика, видео, аудио, картография, диаграммы, отпечатки пальцев и голос, а также сложная цифровая и текстовая информация) потребовали реорганизации существующих систем баз дан­ных. Все это стало причиной возникновения новых технологий баз данных, осно­ванных на объектно-ориентированных концепциях программирования, и появления у реляционных баз данных новых функциональных возможностей, позволяющих обеспечить обработку сложных данных.

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


Мы также рассмотрим основные свойства нового поколения реляционных баз дан­ных, отвечающих требованиям обработки сложных типов данных. Такие базы дан­ных называют расширенными реляционными, или объектно-реляционными базами данных. Мы обсудим общие свойства ОО-систем, не углубляясь в изучение какой-то отдельной реализации ООСУБД.


Преимущества объектно-ориентированного подхода

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

Из этого определения следует, что при использовании объектов модульность прак­тически неизбежна. Объектно-ориентированные концепции широко применяют во многих компьютерных сферах, особенно в сложном программировании и проек­тировании. В табл. П.1 представлены сведения о месте объектно-ориентированного подхода в некоторых компьютерных дисциплинах.

Таблица 11.1. Объектно-ориентированный подход в компьютерном мире






Таблица 11.1 (окончание)

11.2. История развития объектно-ориентированного подхода

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

Понятие объектов впервые возникло в таких языках программирования, как Ada, Algol, LISP и SIMULA. Эти языки программирования были промежуточной ступе­нью до появления языков с более выраженными ОО-концепциями. Наиболее попу­лярными объектно-ориентированными языками программирования (object-oriented programming language, OOPL) можно считать Smalltalk, C++ и Java. Язык Java ис­пользуется при создании Web-приложений, выполняемых в среде Интернет и не зависящих от конкретной операционной системы.

Разработка объектно-ориентированных языков программирования преследовала сле­дующие цели:

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

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


Следовательно, объектно-ориентированная инфраструктура обладает следующими свойствами:

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

Объект может взаимодействовать с другими объектами, тем самым образуя систему объектов. Поскольку такие объекты содержат в себе данные и код, можно достаточ­но просто создать модульную систему с возможностью ее многократного использо­вания. Именно это свойство ОО-системы кажется совершенно естественным тем пользователям, у кого нет большого опыта программирования, но сбивает с толку опытных программистов, привыкших разделять данные и процедуры. Не удивитель­но, что идеи 00 получили быстрое развитие именно с появлением персональных компьютеров (ПК), поскольку на ПК обычно работают обычные пользователи, а не программисты и специалисты по системным разработкам.

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

11.3. Общие принципы объектно-ориентированного подхода

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

11.3.1. Объекты: компоненты и свойства

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

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

Важнейшей характеристикой объекта является его уникальная идентификация. Чтобы особо подчеркнуть этот факт, рассмотрим объект реального мира, представленный | на рис. 11.1. Обратите внимание, что студент (объект) с именем J. D. Wilson имеет уникальную (биологическую) идентификацию и этим отличается от объектов М. R. Gonzalez или V. К. Spelling. Также отметим, что хотя объекты имеют общие основные свойства, например, имя, номер социального страхования, адрес и дату рождения, тем не менее, каждый объект существует во времени и пространстве не­зависимо от других объектов.



Рис. 11.1. Студенты как объекты реального мира

11.3.2. Идентификация объекта

Идентификация объекта выражается идентификатором объекта (object ID, OID), уникальным для данного объекта. Идентификатор (OID) назначается системой в момент создания объекта и не может быть изменен ни при каких условиях. Не надо путать первичный ключ реляционной модели и идентификатор объекта (OID). В отличие от OID, основу первичного ключа составляют значения, опреде­ленные пользователем для данного атрибута, и он может быть изменен в любое вре­мя. Идентификатор 01D назначается системой, не зависит от значений атрибута и его нельзя изменить. OID можно удалить только в том случае, если удаляется сам объект, и данный OID никогда не может быть использован повторно.

11.3.3. Атрибуты (переменные экземпляра)

Объекты описываются их атрибутами, которые в объектно-ориентированной среде называются переменными экземпляра (instance variables). Например, у студента John D. Smith могут быть атрибуты (переменные экземпляра), представленные в табл. 11.2. Каждый атрибут имеет уникальное имя и связанный с ним тип данных. В табл. 11.2 имена атрибутов это SOCIAL_SECURITY_NUMBER (номер социаль­ного страхования), FIRST_NAME (имя), MIDDLEIN1T1AL (отчество или иници­ал), LAST_NAME (фамилия) и т. д. Традиционные типы данных, также называемые

базовыми типами данных (base data types) или договорные типы данных (conventional data types), используются в большинстве языков программирования и включают в себя типы real (вещественный), integer (целый), string (строковый) и т. д. Для атрибутов определены домены. Домен это логическая группа, представляющая собой набор возможных значений данного атрибута. Например, возможные значе­ния атрибута SEMESTER_GPA (средняя оценка за семестр, см. табл. 11.2) могут быть представлены числом типа real из набора базовых типов. Но это не означает, что для GPA (средняя оценка) допустимо любое вещественное число. Нужно иметь в виду, что типы данных определяют базовые домены, т. е. тип real (вещественный) представляет собой все вещественные числа, тип integer — все целые числа, тип date — все возможные даты, тип string — любые комбинации символов и т. д. Одна­ко домены базовых типов данных представляют собой лишь основу, используемую для создания более ограниченных именованных доменов на более высоком логиче­ском уровне. Например, для точного определения домена атрибута GPA мы должны создать домен с именем "GPA". Каждый домен имеет имя и описание, включая ба­зовый тип данных, размер, формат и ограничения на значения домена. Поэтому мы можем определить домен "GPA" как "любое положительное число между 0,00 и 4,00 с двумя знаками после запятой". В данном случае у нас имеется домен с именем "GPA", базовым типом данных real, ограничивающим правилом "любое положитель­ное число между 0,00 и 4,00" и форматом "два знака после запятой". Домен "GPA" предоставляет значения для атрибутов SEMESTER_GPA и OVERALL_GPA. Домены могут также определяться как список возможных значений, разделенных запятыми. Например, домен "GENDER" (пол) может быть определен как "Male, Female" (мужской, женский) или "M,F".

Таблица 11.2. Атрибуты объекта

Имя атрибута Значение атрибута

S OCIAL_SECURITY_NUMBER 414-48-0944

FIRST_NAME John

MIDDLE_NAME D

LAST_NAME Smith

DATE_OF_BIRTH 11/23/1966

MAJOR* Accounting

SEMESTER_GPA 2,89

OVERALL_GPA 3,01

COURSES_TAKEN ENG201;MATH243;HIST201;ACCT211;ECON210;EC

ON212;ACCT212;CIS220;ENG202;MATH301;HIST20 2;CIS310;ACCT343;ACCT345;ENG242;MKTG301;FI N331;ACCT355

ADVISOR Dr. W. R. Learned

* Атрибут, который ссылается на один или более других объектов.


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

Так же как и в ER-модели, атрибут объекта может быть однозначным (иметь одно значение) или многозначным (иметь несколько значений). Следовательно, атрибут объекта может получать из своего домена одно или несколько значений. Например, атрибут SOCIAL_SECURITY_NUMBER получает из домена только одно значе­ние, поскольку данный студент имеет только один номер социального страхования. А такие атрибуты, как Language (язык) или Hobby (увлечение), могут иметь несколь­ко значений, поскольку студент может говорить на нескольких языках и иметь много увлечений.

Атрибуты объекта могут ссылаться на один или более других объектов. Например, атрибут MAJOR (специализация) связан с объектом Department (факультет), атрибут COURSERTAKEN (группы обучения) связан со списком (или набором) объектов Course (группы), а атрибут ADVISOR (куратор) связан с объектом Professor (преподаватель). На уровне реализации для ссылки на объект используется его OID, что позволяет реализовать связи между двумя и более объектами. В табл. 11.2 атри­бут MAJOR содержит 01D объекта Department (English), а атрибут ADVISOR содер­жит OID объекта Professor (Dr. W. R. Learned). Атрибут COURSES_TAKEN содер­жит OID объекта, который содержит список объектов Course. Объект, содержащий в себе список других объектов, называется объект-набор (collection object).




Обратите внимание на разницу между реляционной и объектно-ориентированной моде­лями. В реляционной модели атрибут таблицы может содержать единственное значение, которое можно использовать для соединения (JOIN) строк из различных таблиц. В 00-модели нет необходимости в операторе JOIN для связи объектов друг с другом.

11.3.4. Состояние объекта

Состояние объекта (object state) представляет собой набор значений атрибутов объек­та в данный момент времени. При изменении состояния объекта его OID остается неизменным. Если нужно изменить состояние объекта, то мы должны изменить значения атрибутов объекта. Для этого надо послать объекту сообщение, которое бу­дет инициировать метод.

11.3.5. Сообщения и методы

Метод (method) представляет собой код, выполняющий определенные операции над данными, принадлежащими объекту. Методы защищают данные от прямого и неав­торизованного доступа из других объектов. Чтобы уяснить роль сообщений и мето-

¹ См. С. J. Date and Hugh Darwen, Foundation for Object/Relational Databases: The Third Mani­festo, Addison-Wesley, 1998.



дов, представьте объект в виде ореха. Ядро ореха можно сравнить со структурой данных объекта, а скорлупу — с его методами (рис. 11.2).



Рис. 11.2. Представление объекта

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

Для каждого метода определяются имя (name) и тело (body). Тело состоит из ком­пьютерных инструкций на некотором языке программирования, описывающих не­которое реальное действие. Например, используя атрибуты объекта, приведенные в табл. П.2, мы можем определить метод Avegpa, возвращающий среднюю (average) оценку (GPA) студента на основе атрибутов SEMESTR_GPA и OVERALLGPA объ­екта. Метод с именем Avegpa выполняет следующие преобразования (рис. П.2, а).

Если студент имеет в текущем семестре оценку GPA = 3,2 с нагрузкой 15 часов в семестр, а предыдущая оценка GPA студента была 3,0 при нагрузке 60 часов, то воз­вращаемое методом Avegpa значение будет таким:

(3,2 х 15+3,0x60)/(15+ 60) = (48+ 180)/75 = 3,04

В этом примере обратите внимание, что метод может получать доступ к перемен­ным экземпляра (атрибутам) объекта, для которого этот метод определен.

Для инициализации метода объекту посылается сообщение. При отправлении сооб­щения (message) задаются объект-адресат, имя метода и все необходимые параметры. Отправитель сообщения (другой объект) не может обратиться напрямую к внутрен­ней структуре объекта. Запрет доступа к внутренней структуре объекта гарантирует целостность состояния объекта и скрывает детали внутренней реализации объекта.

Скрытие внутренних деталей объекта (атрибутов и методов) называется инкапсуляци­ей (encapsulation).



Рис. 11.2, а. Действие метода Avegpa





Объект может также посылать сообщения для изменения состояния или опроса те­кущего состояния объекта. (Опрос состояния — interrogate — означает выяснение у целевого объекта текущих значений экземпляров объекта.) Для выполнения этих задач тело метода может содержать ссылки на методы других объектов (отсылка со­общений другим объектам), как это показано на рис. 11.3.

11.3.6. Классы

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

Класс содержит подробное описание структуры данных и реализации методов для объектов данного класса. Поэтому все объекты в классе используют одинаковую структуру и отвечают на одинаковые сообщения. Кроме того, класс действует как "буфер памяти" для схожих объектов. Каждый объект в классе представляет собой экземпляр класса (class instance) или экземпляр объекта (object instance) (рис. 11.4).



Рис. 11.4. Пример класса

Используя пример, представленный ранее в табл. П.2, мы можем определить класс с именем Student для хранения объектов-студентов. Все объекты класса Student, представленные на рис. П.5, используют одинаковую структуру (атрибуты) и отве­чают на одинаковые сообщения (с помощью методов). Обратите внимание, что ра­нее мы уже определили метод Avegpa, а методы Enroll (запись) и Grade (оценка), показанные на рис. П.5, были добавлены позже. Каждый экземпляр класса пред­ставляет собой объект с уникальным OID и каждый объект "знает", к какому классу он принадлежит.



Рис. 11.5. Представление класса Student

t

11.3.7. Протокол





Набор сообщений класса, каждое с определенным именем, составляет протокол класса или объекта. Протокол представляет внешнюю (public) сторону объекта, т. е. он известен другим объектам, а также конечным пользователям. И наоборот, реали­зация структуры объекта и методов представляет внутренний (private) аспект объек­та. Все эти рассуждения проиллюстрированы на рис. 11.6.

Обычно сообщение посылается экземпляру объекта. Однако можно также послать сообщение классу, а не объекту. Когда получателем сообщения является класс, со­общение будет инициировать метод класса. Примером метода класса является метод new. Метод класса new создает новый экземпляр объекта (с уникальным OID) в классе-получателе. Поскольку объект еще не существует, сообщение new адресуется классу, а не объекту.

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



Рис. 11.7. Объектно-ориентированный поход: свойства объекта

11.3.8. Суперклассы, подклассы и наследование

Классы организуются в иерархию классов. Иерархия классов напоминает переверну­тое кроной вниз дерево, в котором у каждого класса есть только один родительский класс. В случае, если классы имеют несколько родительских классов, иерархию классов называют сеткой классов (class lattice). Класс служит для распределения по группам объектов, имеющим одинаковые свойства. Например, класс "Автомобили" включает в себя большие седаны повышенной комфортности, а также небольшие автомобили, а класс "Правительство" включает и федеральное правительство, и пра­вительство штата, и правительство города. На рис. 11.8 показано, что класс "Музыкальные инструменты" включает в себя струнные и духовые инструменты.



Рис. 11.8. Иерархия классов музыкальных инструментов

Обратите внимание на рис. П.8, что классы "Пианино", "Скрипка и "Гитара" явля­ются подклассами класса "Струнные инструменты", который в свою очередь является подклассом класса "Музыкальные инструменты". Класс "Музыкальные инструмен­ты" представляет собой суперкласс для класса "Струнные инструменты", который в свою очередь является суперклассом для классов "Пианино", "Скрипка" и "Гитара". Понятно, что суперкласс является более общим элементом классификации для сво­их подклассов, которые в свою очередь являются более специфическими компонен­тами общей классификации.

Иерархия классов обеспечивает мощную концепцию объектно-ориентированного подхода, которая называется наследованием. Наследование (inheritance) это возмож­ность объекта внутри иерархии наследовать структуру данных и поведение (методы) классов, находящихся выше него. Например, класс "Пианино" на рис. П.8 наследует структуру данных и поведение от суперклассов "Струнные инструменты" и "Музыкальные инструменты". Таким образом, класс "Пианино" наследует наличие струн и характер звучания от суперкласса "Струнные инструменты" и музыкальный строй от суперкласса "Музыкальные инструменты". Именно наследованием в объект­но-ориентированных системах обеспечивается многократное использование кода.

В ОО-системах все объекты производятся от суперкласса Object или класса Root. Поэтому все классы совместно используют свойства и методы суперкласса Object. Наследование данных и методов происходит сверху вниз по иерархии классов. Су­ществуют два варианта наследования: единичное (single) и множественное (multiple).


Единичное наследование

Единичное наследование имеет место, когда над классом есть только один суперкласс (родительский). Такое положение на рис. П.8 иллюстрируется классами "Струнные инструменты" и "Духовые инструменты". Большинство современных ОО-систем поддерживает единичное наследование. Когда система посылает сообщение экземп­ляру объекта, поиск соответствующего метода производится по всей иерархии в сле­дующей последовательности.

1. Сканируется класс, которому принадлежит объект.
   
2. Если метод не найден, сканируется суперкласс.
   

Процесс сканирования повторяется до тех пор, пока не произойдет следующее:

1. Метод найден.
   
2. Достигнут верх иерархии классов, но метод не обнаружен. При этом система
   генерирует сообщение о том, что метод не найден.
   

Для иллюстрации процесса сканирования исследуем иерархию класса Employee (сотрудник), представленную на рис. 11.9. Если мы посылаем сообщение monthPay (ежемесячные выплаты) экземпляру объекта Pilot (пилот), будет выполняться метод monthPay объекта, определенный в его суперклассе Employee. Еще раз обратите вни­мание, что объектно-ориентированные системы обеспечивают многократное исполь­зование кода: код метода monthPay доступен и для подклассов Pilot и Mechanic.



Рис. 11.9. Единичное наследование

Множественное наследование

Множественное наследование имеет место, когда над классом имеется более одного родителя (суперкласса). Такое положение проиллюстрировано на рис. НЛО, где пред­ставлен пример множественного наследования (подкласс "Мотоциклы" наследует свойства как от суперкласса "Транспортное средство", так и от суперкласса "Вело­сипед"). От суперкласса "Транспортное средство" класс "Мотоциклы" наследует:

• свойства (топливо, поршневая группа и мощность);
  
• поведение (запустить двигатель, нажать педаль газа и т. д.).
  

От суперкласса "Велосипед" класс "Мотоцикл" наследует:

• свойства (два колеса и рулевая колонка);
  
• поведение (сесть верхом, повернуть рулевую колонку).
  

Рис. 11.11. Переменные экземпляров классов "Транспортное средство" и "Велосипед"

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

Какую версию переменной экземпляра MAXSPEED будет наследовать метод "Мотоцикл" в этом случае? Человек просто будет использовать для мотоцикла кор­ректное значение 100 миль в час. Однако ОО-система не способна сделать такой выбор и поэтому может:

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

11.3.9. Переопределение методов и полиморфизм

Мы можем переопределить (override) метод суперкласса на уровне подкласса. Для иллюстрации переопределения метода используем иерархию класса Employee, пред­ставленную на рис. 11.12.



Рис. 11.12. Переопределение метода иерархии класса Employee

На рис. П. 12 следует обратить внимание, что для расчета премии к Рождеству для всех сотрудников мы определили метод Bonus (премия). Расчет премии зависит от специализации сотрудника. В данном случае каждый сотрудник, за исключением пилотов, получает премию к рождеству в размере 5% от годовой заработной платы. Пилоты получают Рождественскую премию на основе налетанных часов (ACCUMFLIGHTPAY), а не на основе годовой зарплаты. Определяя метод Bonus в подклассе Pilot (пилоты), мы переопределяем метод Bonus класса Employee для всех объектов, принадлежащих подклассу Pilot. При этом переопределение метода Bonus в подклассе Pilot не повлияет на расчет премии в подклассе Mechanic (механики). В отличие от переопределения методов, полиморфизм (polymorphism) позволяет раз­личным объектам реагировать на одно и то же сообщение различными способами. Полиморфизм — очень важная функция ОО-систем, поскольку его существование позволяет объектам вести себя в соответствии с их специфическими свойствами. В терминах 00 полиморфизм означает:

• возможность использования одинаковых имен для методов, определенных в раз­
  личных классах иерархии;
  
• пользователь может посылать одинаковые сообщения различным объектам, при­
  надлежащим различным классам, и при этом получать корректный ответ.
  

Чтобы проиллюстрировать эффект полиморфизма, исследуем расширенную иерар­хию класса Employee, представленную на рис. 11.13. На базе этой иерархии система рассчитывает ежемесячные выплаты пилотам или механикам, посылая одно и то же сообщение monthPay объекту Pilot или Mechanic. Объект возвращает корректное значение выплаты, даже если в monthPay включается flyPay (оплата полета), свойст­венная объекту Pilot, и overtimePay (оплата сверхурочных), свойственная объекту Mechanic. Порядок расчета ежемесячной зарплаты для обоих подклассов (Pilot и Mechanic) один и тот же: годовой оклад делится на 12 месяцев.

На рис. 11.13 использован синтаксис Smalltalk: Выражение Super monthPay в методе monthPay класса Pilot указывает, что объект наследует метод monthPay суперкласса. Другие объектно-ориентированные языки программирования, например, C++, используют запись с точкой: Employee.monthPay.

На рис. 11.13 следует обратить внимание на следующие особенности полиморфизма:

• определение метода monthPay класса Pilot переопределяет и расширяет метод monthPay суперкласса Employee;
  
• метод monthPay, определенный в суперклассе Employee, повторно используется подклассами Pilot и Mechanic.
  

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