учебники, программирование, основы, введение в,

 

Введение в наследование

Многоугольники и прямоугольники
Для объяснения основных понятий рассмотрим простой пример. Здесь приведен скорее набросок этого примера, а не полный его вариант, но он хорошо показывает все существенные идеи.
Многоугольники
Предположим, что требуется построить графическую библиотеку. Ее классы будут описывать геометрические абстракции: точки, отрезки, векторы, круги, эллипсы, многоугольники, треугольники, прямоугольники, квадраты и т. п.
Рассмотрим вначале класс, описывающий многоугольники. Операции будут включать вычисление периметра, параллельный перенос и вращение. Этот класс может выглядеть так:
indexing
description: "Многоугольники с произвольным числом вершин"
class POLYGON creation
...
feature -- Доступ
count: INTEGER
-- Число вершин
perimeter: REAL is
-- Длина периметра
do ... end
feature -- Преобразование
display is
-- Вывод многоугольника на экран.
do ... end
rotate (center: POINT; angle: REAL) is
-- Поворот на угол angle вокруг точки center.
do
... См. далее ...
end
translate (a, b: REAL) is
-- Сдвиг на a по горизонтали, на b по вертикали.
do ... end
... Объявления других компонентов ...
feature {NONE} -- Реализация
vertices: LINKED_LIST [POINT]
-- Список вершин многоугольника
invariant
same_count_as_implementation: count = vertices.count
at_least_three: count >= 3
-- У многоугольника не менее трех вершин (см. упражнение У14.2)
end

Атрибут vertices задает список вершин, выбор линейного списка - это лишь одно из возможных представлений (массив мог бы оказаться лучше).
Приведем реализацию типичной процедуры rotate. Эта процедура осуществляет поворот на заданный угол вокруг заданного центра поворота. Для поворота многоугольника достаточно повернуть по очереди каждую его вершину.
rotate (center: POINT; angle: REAL) is
-- Поворот вокруг точки center на угол angle.
do
from
vertices.start
until
vertices.after
loop
vertices.item.rotate (center, angle)
vertices.forth
end
end

Чтобы понять эту процедуру заметим, что компонент item из LINKED_LIST возвращает значение текущего элемента списка. Поскольку vertices имеют тип LINKED_LIST [POINT], то vertices.item обозначает точку, к которой можно применить процедуру поворота rotate, определенную для класса POINT в предыдущей лекции. Это вполне корректно и достаточно общепринято - давать одно и то же имя (в данном случае rotate), компонентам разных классов, поскольку результирующее множество каждого из них имеет свой явно определенный тип. (Это ОО-форма перегрузки.)
Более важна для наших целей процедура вычисления периметра многоугольника. Единственный способ вычислить периметр многоугольника - это в цикле пройти по всем его вершинам и просуммировать длины всех ребер. Вот возможная реализация процедуры perimeter:
perimeter: REAL is
-- Сумма длин ребер
local
this, previous: POINT
do
from
vertices.start; this := vertices.item
check not vertices.after end -- Следствие условия at_least_three
until
vertices.is_last
loop
previous := this
vertices.forth
this := vertices.item
Result := Result + this.distance (previous)
end
Result := Result + this.distance (vertices.first)
end

В этом цикле просто последовательно складываются расстояния между соседними вершинами. Функция distance была определена в классе POINT. Значение Result, возвращаемое этой функцией, при инициализации получает значение 0. Из класса LINKED_LIST используются следующие компоненты: first дает первый элемент списка, start сдвигает курсор, на этот первый элемент, forth передвигает его на следующий, item выдает значение элемента под курсором, is_last определяет, является ли текущий элемент последним, after узнает, что курсор оказался за последним элементом. Как указано в команде check инвариант at_least_three обеспечивает правильное начало и завершение цикла. Он стартует в состоянии not after, в котором элемент vertices.item определен. Допустимо применение forth один или более раз, что, в конце концов, приведет в состояние, удовлетворяющее условию выхода из цикла is_last.
Прямоугольники
Предположим теперь, что нам требуется новый класс, представляющий прямоугольники. Можно было бы начать его проектировать заново. Но прямоугольники это специальный вид многоугольников и у них много общих компонент: их также можно сдвигать, поворачивать и выводить на экран. С другой стороны, у них есть ряд специфических компонентов (например, диагонали), специальные свойства (число вершин равно четырем, а углы являются прямыми) и возможны специальные варианты некоторых операций (вычисление периметра можно устроить проще, чем в приведенном выше алгоритме).
Преимущества такой смеси общих и специфических компонентов можно использовать, определив класс RECTANGLE как наследника (heir) класса POLYGON. При этом все компоненты класса POLYGON, называемого родителем (parent) класса RECTANGLE, по умолчанию будут применимы и к классу-наследнику. Для этого достаточно включить в RECTANGLE предложение наследования (inheritance clause):
class RECTANGLE inherit
POLYGON
feature
... Компоненты, специфичные для прямоугольников ...
end

В предложении feature класса-наследника компоненты родителя не повторяются: они автоматически доступны благодаря предложению о наследовании. В нем будут указаны лишь компоненты, специфичные для наследника. Это могут быть новые компоненты, такие как diagonal, а также переопределяемые наследуемые компоненты.
Вторая возможность полезна для такого компонента, который уже имелся у родителя, но у наследника должен быть описан в другом виде. Рассмотрим периметр perimeter. Для прямоугольников его можно вычислить более эффективно: не нужно вычислять четыре длины сторон, достаточно удвоить сумму длин двух сторон. Наследник, переопределяющий некоторый компонент родителя, должен объявить об этом в предложении наследования, включив предложение redefine:
class RECTANGLE inherit
POLYGON
redefine perimeter end
feature
...
end

Это позволяет включить в предложение feature класса RECTANGLE новую версию компонента perimeter, которая заменит его версию из класса POLYGON. Если не включить объявление redefine, то новое объявление компонента perimeter среди других компонентов класса RECTANGLE приведет к ошибке, поскольку у RECTANGLE уже есть компонент perimeter, унаследованный от POLYGON, т.е. у некоторого компонента окажется два определения.
Класс RECTANGLE выглядит следующим образом:
indexing
description: "Прямоугольники, - специальный случай многоугольников"
class RECTANGLE inherit
POLYGON
redefine perimeter end
creation
make
feature -- Инициализация
make (center: POINT; s1, s2, angle: REAL) is
-- Установить центр прямоугольника в center, длины сторон
-- s1 и s2 и ориентацию angle.
do ... end
feature -- Access
side1, side2: REAL
-- Длины двух сторон
diagonal: REAL
-- Длина диагонали
perimeter: REAL is
-- Сумма длин сторон
-- (Переопределение версии из POLYGON)
do
Result := 2 S (side1 + side2)
end
invariant
four_sides: count = 4

first_side: (vertices.i_th (1)).distance (vertices.i_th (2)) = side1
second_side: (vertices.i_th (2)).distance (vertices.i_th (3)) = side2
third_side: (vertices.i_th (3)).distance (vertices.i_th (4)) = side1
fourth_side: (vertices.i_th (4)).distance (vertices.i_th (1)) = side2
end


Для списка i_th(i) дает элемент в позиции i ( i-й элемент, следовательно это имя запроса).

Так как RECTANGLE является наследником класса POLYGON, то все компоненты родительского класса применимы и к новому классу: vertices, rotate, translate, perimeter (в переопределенном виде) и все остальные. Их не нужно повторять в определении нового класса.
Этот процесс транзитивен: всякий класс, будучи наследником RECTANGLE, например, SQUARE, также обладает всеми компонентами класса POLYGON.
Основные соглашения и терминология
Кроме терминов "наследник" и "родитель" будут полезны следующие термины:
Терминология наследования
Потомок класса C - это любой класс, который наследует C явно или неявно, включая и сам класс C. (Формально, это либо C, либо, по рекурсии, потомок некоторого наследника C).
Собственный потомок класса C - это потомок, отличный от самого C.
Предок C - это такой класс A, для которого C является потомком. Собственный предок C - это такой класс A, для которого C является собственным потомком.
В литературе также встречаются термины "подкласс" и "суперкласс", но мы не будем их использовать из-за неоднозначности.
Имеется также терминология для компонентов класса: компонент либо является наследуемым (перешедшим от некоторого собственного предка), либо непосредственным (введенным в данном классе).
При графическом представлении структур ОО-ПО, в котором классы изображаются эллипсами, связи по отношению наследования показываются в виде одинарных стрелок. Тем самым они отличаются от связей по отношению "быть клиентом", которые представляются двойными стрелками.
Переопределяемый компонент отмечается ++ (это соглашение принято в Business Object Notation (B.O.N.)).
Стрелка указывает вверх от наследника к родителю. Это соглашение легко запомнить - оно представляет отношение "наследовать от". В литературе встречается и обратное направление таких стрелок. Хотя обычно выбор графического представления является делом вкуса, в данном случае, одно из них явно лучше другого, поскольку одно наводит на мысль о правильном отношении, а другое может привести к путанице. Стрелка - это не просто произвольная пиктограмма, она указывает на одностороннюю связь между своими двумя концами. В данном случае:

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

Хотя у нас нет жесткого правила, определяющего для достаточно сложных систем размещение классов на диаграммах наследования, мы будем, по возможности, помещать класс выше его наследника.
Наследование инварианта
Хотелось бы указать инвариант класса RECTANGLE, который говорил бы, что число сторон прямоугольника равно четырем и что длины сторон последовательно равны side1, side2, side1 и side2.
У класса POLYGON также имеется инвариант, который применим и к его наследнику:
Правило наследования инварианта
Инвариант класса является конъюнкцией утверждений из его раздела invariant и свойств инвариантов его родителей (если таковые имеются).
Поскольку у родителей класса могут быть свои родители, то это правило рекурсивно: в результате полный инвариант класса получается как конъюнкция собственного инварианта и инвариантов классов всех его предков.
Это правило отражает одну из важных характеристик наследования: сказать, что B наследует A - это утверждать, что каждый экземпляр B является также экземпляром A. Вследствие этого всякое выраженное инвариантом ограничение целостности, применимое к экземплярам A, будет также применимо и к экземплярам B.
В нашем примере второе предложение (at_least_three) инварианта POLYGON утверждает, что число сторон должно быть не менее трех, оно является следствием предложения four_sides из инварианта класса RECTANGLE, которое требует, чтобы сторон было ровно четыре.
Наследование и конструкторы
Ранее не показанная процедура создания (конструктор) для класса POLYGON может иметь вид
make_polygon (vl: LINKED_LIST [POINT]) is
-- Создание по вершинам из vl.
require
vl.count >= 3
do
...Инициализация представления многоугольника по элементам из vl ...
ensure
-- vertices и vl состоят из одинаковых элементов (это можно выразить
формально)
end

Эта процедура берет список точек, содержащий по крайней мере три элемента, и использует его для создания многоугольника.


Ей дано собственное имя make_polygon, чтобы избежать конфликта имен при ее наследовании классом RECTANGLE, у которого имеется собственная процедура создания make. Мы не рекомендуем так делать в общем случае, в следующей лекции будет показано, как давать процедуре создания класса POLYGON стандартное имя make, а затем использовать переименование в предложении о наследовании класса RECTANGLE, чтобы предотвратить коллизию имен.

Приведенная выше процедура создания класса RECTANGLE имеет четыре аргумента: точку, служащую центром, длины двух сторон и ориентацию. Отметим, что компонент vertices применим к прямоугольникам, поэтому процедура создания для RECTANGLE создает список вершин vertices (четыре угла вычисляются по центру, длинам сторон и ориентации).
Общая процедура создания для многоугольников не удобна прямоугольникам, так как приемлемы только списки из четырех элементов, удовлетворяющих инварианту класса RECTANGLE. Процедура создания для прямоугольников, в свою очередь, не годится для произвольных многоугольников. Это обычное дело: процедура создания родителя не подходит для наследника. Нельзя гарантировать, что она будет удовлетворять его новому инварианту.
Например, если у наследника имеются новые атрибуты, то процедуре создания нужно будет их инициализировать, для чего потребуются дополнительные аргументы. Отсюда общее правило:
Правило наследования конструктора
При наследовании свойство процедуры быть конструктором не сохраняется.
Наследуемая процедура создания все еще доступна в наследнике, как и любой другой компонент родителя, но она не сохраняет статус конструктора. Этим статусом обладают только процедуры, перечисленные в предложении creation наследника.
В некоторых случаях родительский конструктор подходит и для наследника. Тогда его просто нужно указать в предложении creation:
class B inherit
A
creation
make
feature
...

где процедура make наследуется без изменений от класса A, у которого она также указана в предложении creation.
Пример иерархии
В конце обсуждения полезно рассмотреть пример POLYGON-RECTANGLE в контексте более общей иерархии типов геометрических фигур.
Фигуры разбиты на замкнутые и незамкнутые. Примером замкнутой фигуры кроме многоугольника является также эллипс, а частным случаем эллипса является круг.
Рядом с классами указаны их разные компоненты. Символ "++" означает "переопределено", а символы "+" и "*" будут объяснены далее.
Ранее для простоты RECTANGLE был наследником класса POLYGON. Поскольку указанная классификация основана на числе вершин, то представляется разумным ввести промежуточный класс QUADRANGLE для четырехугольников на том же уровне, что и классы TRIANGLE, PENTAGON и т. п. Тогда компонент diagonal (диагональ) можно переместить на уровень класса QUADRANGLE.
Отметим, что класс SQUARE, наследник класса RECTANGLE, характеризуется инвариантом side1 = side2. Аналогично, у эллипса имеются два фокуса, а у круга они сливаются в один, что определяет инвариант класса CIRCLE: equal (focus1 = focus2).

Полиморфизм

Иерархии наследования позволяют достаточно гибко работать с объектами, сохраняя надежность статической типизации. Поддерживающие их методы: полиморфизм и динамическое связывание - одни из самых фундаментальных аспектов архитектуры ПО, обсуждаемой в этой книге. Начнем с полиморфизма.
Полиморфное присоединение
"Полиморфизм" означает способность обладать несколькими формами. В ОО-разработке несколькими формами обладают сущности (элементы структур данных), способные во время выполнения присоединяться к объектам разных типов, что контролируется статическими объявлениями.
Предположим, что для структуры наследования на рисунке вверху объявлены следующие сущности:
p: POLYGON; r: RECTANGLE; t: TRIANGLE

Тогда допустимы следующие присваивания:
p := r
p := t

Эти команды присваивают в качестве значения сущности, обозначающей многоугольник, сущность, обозначающую прямоугольник в первом случае, и сущность, обозначающую треугольник - во втором.
Такие присваивания, в которых тип источника (правой части) отличен от типа цели (левой части), называются полиморфными присваиваниями. Сущность, входящая в полиморфное присваивание слева (в примере это p) является полиморфной сущностью.
До введения наследования все присваивания были мономорфными (не полиморфными): можно было присваивать точку точке, книгу книге, счет счету. С появлением полиморфизма возможных действий становится больше.
Приведенные в примере полиморфные присваивания легитимны, поскольку структура наследования позволяет рассматривать экземпляр класса RECTANGLE или TRIANGLE как экземпляр класса POLYGON. Мы говорим, что в таком случае тип источника согласован с типом цели. В обратном направлении присваивание недопустимо, т.е. некорректно писать r := p. Вскоре это важное правило будет рассмотрено более подробно.
Кроме присваивания, полиморфизм имеет место и при передаче аргументов, например в вызовах вида f (r) или f (t) при условии объявлении компонента f в виде:
f (p: POLYGON) is do ... end

Напомним, что присваивание и передача аргументов имеют одинаковую семантику, и оба называются присоединением (attachment). Когда источник и цель имеют разные типы, можно говорить о полиморфном (polymorphic) присоединении.
Что на самом деле происходит при полиморфном присоединении?
Все сущности, встречающиеся в предыдущих примерах полиморфных присваиваний, имеют тип ссылок: возможными значениями p, r и t являются не объекты, а ссылки на объекты. Поэтому результатом присваивания p := r является просто новое присоединение ссылки.
Несмотря на название, не следует представлять полиморфизм как некоторую трансмутацию объектов во время выполнения программы. Будучи один раз создан, объект никогда не изменяет свой тип. Так могут поступать только ссылки, которые могут указывать на объекты разных типов. Отсюда также следует, что за полиморфизм не нужно платить потерей эффективности, перенаправление ссылки - очень быстрая операция, ее стоимость не зависит от включенных в эту операцию объектов.
Полиморфные присоединения допускаются только для целей типа ссылки, но, ни в коем случае, для расширенных типов. Поскольку у класса-потомка могут быть новые атрибуты, то соответствующие ему экземпляры могут иметь больше полей. Навидно, что объект класса RECTANGLE больше, чем объект класса POLYGON. Такая разница в размерах объектов не приводит к проблемам, если все, что заново присоединяется, имеет тип ссылки. Но если p - не ссылка, а имеет развернутый тип (например, объявлена как expanded POLYGON), то значением p является непосредственно некоторый объект, и всякое присваивание p будет менять содержимое этого объекта. В этом случае никакой полиморфизм невозможен.
Полиморфные структуры данных
Рассмотрим массив многоугольников:
poly_arr: ARRAY [POLYGON]

Когда некоторое значение x присваивается элементу этого массива, как в вызове
poly_arr.put (x, some_index)

(для некоторого допустимого значения индекса some_index), то спецификация класса ARRAY указывает, что тип присваиваемого значения должен быть согласован с типом фактического родового параметра:
class ARRAY [G] creation
...
feature - Изменение элемента
put (v: G; i: INTEGER) is
-- Присвоить v элементу с индексом i
...
end

Так как тип формального аргумента v, соответствующего x, в классе определен как G, а фактический родовой параметр, соответствующий G в вызове poly_arr, - это POLYGON, то тип x должен быть согласован с ним. Как мы видели, для этого x не обязан иметь тип POLYGON, подойдет любой потомок типа POLYGON.
Поэтому, если границы массива равны 1 и 4, то можно объявить некоторые сущности:
p: POLYGON; r: RECTANGLE; s: SQUARE; t: TRIANGLE

и, создав соответствующие объекты, можно выполнить операции
poly_arr.put (p, 1)
poly_arr.put (r, 2)
poly_arr.put (s, 3)
poly_arr.put (t, 4)

которые присвоят элементам массива ссылки на объекты различных типов.


На этом рисунке графические объекты представлены соответствующими геометрическими фигурами, а не обычными диаграммами объектов с набором их полей.

Такие структуры данных, содержащие объекты разных типов, имеющих общего предка, называются полиморфными структурами данных. Далее будут рассмотрены многочисленные примеры таких структур. Массивы - это только одна из возможностей, полиморфными могут быть любые структуры контейнеров: списки, стеки и т.п.
Полиморфные структуры данных реализуют цель, сформулированную в начале лекции: объединение порождения и наследования для достижения максимальной гибкости и надежности. Имеет смысл напомнить, иллюстрирующий эту мысль:
Типы, которые нанеформально назывались SET_OF_BOOKS и т. п., заменены типами, выведенными из родового универсального типа, - SET [BOOK].
Такая комбинация универсальности и наследования является весьма сильным средством. Оно позволяет описывать структуру объектов с нужной степенью общности. Например,
LIST [RECTANGLE]: может содержать квадраты, но не треугольники.
LIST [POLYGON]: может содержать квадраты, прямоугольники, треугольники, но не круги.
LIST [FIGURE]: может содержать экземпляры любого типа из иерархии FIGURE, но не книги или банковские счета.
LIST [ANY]: может содержать объекты любого типа.
В последнем случае использован класс ANY, который условимся считать предком любого класса (он будет подробнее рассмотрен далее).
Варьируя место класса, выбираемого в качестве фактического родового параметра, в иерархии, можно точно установить границы типов объектов, допустимых в определяемом контейнере.

Типизация при наследовании

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

r: RECTANGLE

Выделим в приведенной выше иерархии нужный фрагмент .
Тогда законны следующие выражения:

  • p.perimeter: никаких проблем, поскольку perimeter определен для многоугольников;
  • p.vertices, p.translate (...), p.rotate (...) с корректными аргументами;
  • r.diagonal, r.side1, r.side2: эти три компонента объявлены на уровне RECTANGLE или QUADRANGLE;
  • r.vertices, r.translate (...), r.rotate (...): эти компоненты объявлены на уровне POLYGON или еще выше и поэтому применимы к прямоугольникам, наследующим все компоненты многоугольников;
  • r.perimeter: то же, что и в предыдущем случае. Но у вызываемой здесь функции имеется новое определение в классе RECTANGLE, так что она отличается от функции с тем же именем из класса POLYGON.

А следующие вызовы компонентов незаконны, так как эти компоненты недоступны на уровне многоугольника:
p.side1
p.side2
p.diagonal

Это рассмотрение основано на первом фундаментальном правиле типизации:
Правило Вызова Компонентов
Если тип сущности x основан на классе С, то в вызове компонента x.f сам компонент f должен быть определен в одном из предков С.
Напомним, что класс С является собственным предком. Фраза "тип сущности x основан на классе С" напоминает, что для классов, порожденных из родовых, тип может включать не только имя класса: LINKED_LIST [INTEGER]. Но базовый класс для типа - это LINKED_LIST, так что родовой параметр никак не участвует в нашем правиле.
Как и все другие правила корректности, рассматриваемые в этой книге, правило Вызова Компонентов является статическим, - его можно проверять на основе текста системы, а не по ходу ее выполнения. Компилятор (который, как правило, выполняет такую проверку) будет отвергать классы, содержащие некорректные вызовы компонентов. Если успешно реализовать проверку правил типизации, то не возникнет риск того, что скомпилированная система когда-либо во время выполнения применит некоторый компонент к объекту неподходящего типа.
Статическая типизация - это один из главных ресурсов ОО-технологии для достижения объявленной в 1-ой лекции цели - надежности ПО.


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

Пределы полиморфизма
Неограниченный полиморфизм был бы несовместим со статическим понятием типа. Допустимость полиморфных операций определяется наследственностью.
Все примеры полиморфных присваиваний, такие, как p := r и p := t, в качестве типа источника используют потомков класса-цели. Скажем, что в таком случае тип источника согласован с классом цели. Например, SQUARE согласован с RECTANGLE и с POLYGON, но не с TRIANGLE. Чтобы уточнить это понятие, дадим формальное определение:
Определение: согласованность
Тип U согласован с типом T, только если базовый класс для U является потомком базового класса для T; при этом для универсально порожденных типов каждый фактический параметр U должен (по рекурсии) быть согласован с соответствующим формальным параметром T.
Почему недостаточно понятия потомка в этом определении? Причина снова в том, что допускается порождение из родовых классов, поэтому приходится различать типы и классы. Для каждого типа имеется базовый класс, который при отсутствии порождения совпадает с самим типом (например, POLYGON является базовым для себя). При этом для универсально порожденного класса базовым является универсальный класс с опущенными родовыми параметрами. Например, для класса LIST [POLYGON] базовым будет класс LIST. Вторая часть определения говорит о том, что B [Y] будет согласован с A [X], если B является потомком A, а Y - потомком X.
Заметим, что поскольку каждый класс является собственным потомком, то каждый тип согласован сам с собой.
При таком обобщении понятия потомка получаем второе важное правило типизации:
Правило согласования типов
Присоединение к источнику y цели x (т. е. присваивание x:=y или использование y в качестве фактического параметра в вызове процедуры с соответствующим формальным параметром x) допустимо только тогда, когда тип y согласован с типом x.
Правило согласования типов выражает тот факт, что специальное можно присваивать общему, но не наоборот. Поэтому присваивание p := r допустимо, а r := p нет.


Это правило можно проиллюстрировать следующим образом. Предположим, что я настолько ненормален, что послал в компанию Любимцы-По-Почте заказ на "Animal" ("Животное"). В этом случае, что бы я ни получил: собаку, божью коровку или дельфина-касатку, у меня не будет права пожаловаться. (Предполагается, что DOG и все прочие являются потомками класса ANIMAL). Но если я заказал собаку, а почтальон принес мне утром коробку с надписью ANIMAL, или, например, MAMMAL (млекопитающее), то я имею право вернуть ее отправителю, даже если из нее доносится недвусмысленный лай и тявканье. Поскольку мой заказ не был исполнен в соответствии со спецификацией, я ничего не должен фирме Любимцы-По-Почте.

Экземпляры
С введением полиморфизма нам требуется уточнить терминологию, связанную с экземплярами. Содержательно, экземпляры класса - это объекты времени выполнения, построенные в соответствии с определением класса. Но сейчас в этом качестве нужно также рассматривать объекты, построенные для собственных потомков класса. Вот более точное определение:
Определение: прямой экземпляр, экземпляр
Прямой экземпляр класса C - это объект, созданный в соответствии с точным определением C с помощью команды создания create x ..., в которой цель x имеет тип C (или, рекурсивно, путем клонирования прямого экземпляра C).
Экземпляр C - это прямой экземпляр потомка C.
Из последней части этого определения следует, что прямой экземпляр класса C является также экземпляром C, так как класс входит во множество своих потомков.
Таким образом, выполнение фрагмента:
p1, p2: POLYGON; r: RECTANGLE
...
create p1 ...; create r ...; p2 := r

создаст два экземпляра класса POLYGON, но лишь один прямой экземпляр (тот, который присоединен к p1). Другой объект, на который указывают p2 и r, является прямым экземпляром класса RECTANGLE, а следовательно, экземпляром обоих классов POLYGON и RECTANGLE.
Хотя понятия прямого экземпляра и экземпляра определены выше для классов, они естественно распространяются на любые типы (с базовым классом и возможными родовыми параметрами).
Полиморфизм означает, что элемент некоторого типа может присоединяться не только к прямым экземплярам этого типа, но и к другим его экземплярам. Можно считать, что роль правила согласования типов состоит в обеспечении следующего свойства:
Статико-динамическая согласованность типов
Сущность типа T может во время исполнения прикрепляться только к экземплярам класса T.
Статический тип, динамический тип
Название последнего свойства предполагает различение "статического типа" и "динамического типа". Тип, который используется при объявлении некоторого элемента, является статическим типом соответствующей ссылки. Если во время выполнения эта ссылка присоединяется к объекту некоторого типа, то этот тип становится динамическим типом этой ссылки.
Таким образом, при объявлении p: POLYGON статический тип ссылки, обозначенной p, есть POLYGON, после выполнения create p динамическим типом этой ссылки также является POLYGON, а после присваивания p := r, где r имеет тип RECTANGLE и не пусто, динамическим типом становится RECTANGLE.
Правило согласования типов утверждает, что динамический тип всегда должен соответствовать статическому типу.
Чтобы избежать путаницы напомним, что мы имеем дело с тремя уровнями: сущность - это некоторый идентификатор в тексте класса, во время выполнения ее значение является ссылкой (за исключением развернутого случая), ссылка может быть присоединена к объекту.
У объекта имеется только динамический тип, который он получил в момент создания. Этот тип во время жизни объекта не изменяется.
В каждый момент во время выполнения у ссылки имеется динамический тип, тип того объекта, к которому она сейчас присоединена (или специальный тип NONE, если эта ссылка пуста). Динамический тип может изменяться в результате операций переприсоединения.
Только у сущности имеются и статический, и динамический типы. Ее статический тип - это тип, с которым она была объявлена: если объявление имеет вид x: T, то этим типом будет T. Ее динамический тип в каждый момент выполнения - это тип значения этой ссылки, т.е. того объекта, к которому она присоединена.


В развернутом случае нет ссылки, значением x является объект типа T, и T является и статическим типом и единственно возможным динамическим типом для x.

Обоснованы ли ограничения?
Приведенные выше правила типизации могут иногда показаться слишком строгими. Например, второй оператор в обоих случаях статически отвергается:

  • p:= r; r := p
  •              
  • p := r; x := p.diagonal
  •              

В (1) запрещается присваивать многоугольник сущности-прямоугольнику, хотя во время выполнения так получилось, что этот многоугольник является прямоугольником (аналогично тому, как можно отказаться принять собаку из-за того, что на клетке написано "животное"). В (2) компонент diagonal оказался не применим к p несмотря на то, что во время выполнения он, фактически, присутствует.
Но более аккуратный анализ показывает, что наши правила вполне обоснованы. Если ссылка присоединяется к объекту, то лучше избежать будущих проблем, убедившись в том, что их типы согласованы. А если хочется применить некоторую операцию прямоугольника, то почему бы сразу не объявить цель прямоугольником?
На практике, случаи вида (1) и (2) маловероятны. Присваивания типа p:= r обычно встречаются внутри некоторых управляющих структур, которые зависят от условий, определяемых во время выполнения, например, от ввода данных пользователем. Более реалистичная полиморфная схема может выглядеть так:
create r.make (...); ...
screen.display_icons                -- Вывод значков для разных многоугольников
screen.wait_for_mouse_click        -- Ожидание щелчка кнопкой мыши
x := screen.mouse_position          -- Определение места нажатия кнопки
chosen_icon := screen.icon_where_is (x)    -- Определение значка,
-- на котором находится указатель мыши
if chosen_icon = rectangle_icon then
p := r
elseif ...
p := "Многоугольник другого типа" ...
end
... Использование p, например, p.display, p.rotate, ...

В последней строке p может обозначать любой многоугольник, поэтому можно к нему применять только общие компоненты из класса POLYGON. Понятно, что операции, подходящие для прямоугольников, такие как diagonal, должны применяться только к r (например, в первом предложении if). Если придется использовать p в операторах, следующих за оператором if, то к нему могут применяться лишь операции, применимые ко всем видам многоугольников.
В другом типичном случае p просто является формальным параметром процедуры:
some_routine (p: POLYGON) is ...

и можно выполнять вызов some_routine (r), корректный в соответствии с правилом согласования типов. Но при написании процедуры об этом вызове еще ничего не известно. На самом деле, вызов some_routine (t) для t типа TRIANGLE или любого другого потомка класса POLYGON будет также корректен, таким образом, можно считать, что p представляет некоторый вид многоугольников - любой из их видов. Тогда вполне разумно, что к p применимы только компоненты класса POLYGON.
Таким образом, в случае, когда невозможно предсказать точный тип присоединяемого объекта, полиморфные сущности (такие как p) весьма полезны.

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика