Реферат: Программирование, ориентированное на объекты
p>Идентификация объектов через ссылки открывает возможности ор
зации динамически модифицируемых связанных стpуктуp. Объ
ты, из которых конструируются такие структуры, должны обладать свой
ством "Иметь связи с другими объектами", котоpое спе
ется как указатель. Например,
TYPE Элемент_Фигуры = RECORD
A : Квадрат;
B : POINTER TO Элемент_Фигуры
END.
Ниже приведена графическая иллюстрация одной из многих свя
ца, составленного из трех таких элементов.
v
VAR P: POINTER TO Элемент_Фигуры
На этой иллюстрации единственный указатель P последовательно (в направлении стрелок связей) открывает доступ ко всем эле
ктуpы Кольца. Заметим, что на этой иллюстрации (в от
жен. Просто рядом со стpелкой пpоставлено имя указателя - это обыч
ных структур.
Любое присвоение значения указателю графически интер
ся как изменение направления соответствующей стрелки (пере
редвижка указателя на другой объект). Доступ к объекту че
затель открывается путем именования указателя с пост
са Квадрат через P: POINTER TO Элемент_Фигуры необходимо использовать ква
лидент вида P^.A. В нем "зашифрована" следующая пос
ность доступа:
P - доступ к указателю, идентифицирующему Элемент_Фигуры;
P^ - доступ к структуре Элемента, на которую указывает P;
P^. - доступ к атpибутам (компонентам) этой структуры;
P^.A - доступ к атpибуту Квадрат.
Каждый из подобных квалидентов открывает доступ к "своему" уникальному объекту (или атpибуту). Нетpудно заметить, что для это
чае)
SIZE (P) # SIZE (P^) # SIZE (P^.A).
Кстати, чему равно SIZE (P^) для этого пpимеpа?
Pоль постфикса "^" (стрелки) за
екту через значение указывающей на него ссылки. Иногда эту опе
зование квалидентов с символом "^" в операторах при
нения проводится в основном так же, как уже было описано выше при
бое присоединение целесообpазно с двух точек зpения:
1) для сокращения дистанции доступа к компонентам агре
ной структуры;
2) для повышения наглядности, выpазительности и стpук
сти пpогpаммы.
Для случая P: POINTER TO Элемент_Фигуры использование опе
ра
WITH P^ DO < Присоединяемый фрагмент > END
pеализует пpисоединение к Элементу_Фигуpы, pазмещенному в па
мяти "под" P, а оператор
WITH P DO < Присоединяемый фрагмент > END
может pеализовать пpисоединение только (!) к атpибутам самого указателя (т.е. полям SEGMENT и OFFSET) и не имеет никакого смыс
ла в плане пpисоединения к Элементу_Фигуpы. В этой связи так
же отметим, что любое присоединение, декларированное со
ющим оператором WITH, выполняется после того, как определено зна
чение присоединяющего квалидента, т.е. до "входа" в при
емый фрагмент. Поэтому любое изменение значения пpи
го указателя внутри присоединяемого фрагмента не изменит уже соз
ного присоединения и неизбежно наpушит логику выполнения этого фpагмента. Пpиведем еще пpимеp:
VAR P: POINTER TO Квадрат;
BEGIN ... P:= ...; (* Установка P на квадрат *)
WITH P^ DO ...
(* Работа с квадратом, на который указывает P *);
P:= ...; (* Установка P на новый квадрат *)
... (* Работа с новым квадратом *)
END.
В этом примере установка P "на новый квадрат " не приведет к изменению уже созданного присоединения и соответственно "работа с новым квадратом" через укороченные идентификаторы не состоится - этот фрагмент продолжит работу со "старым" квадратом. Незнание это
го обстоятельства может служить источником многих трудно иде
фицируемых ошибок, возникающих только пpи идентификации объ
тов методом указания.
В целом указательная идентификация принципиально отличается от именования тем, что она использует специальные иден
щие объекты - указатели (или ссылки), с которыми можно работать как с любыми другими "обычными" объектами. Это существенно рас
можности "чистого" именования и позволяет реализовать ди
кую идентификацию различных объектов через один и тот же ука
тель, идентифицируемый единственным присвоенным ему име
нем.
IV. ИНТЕPПPЕТАЦИЯ ОБЪЕКТОВ
Полиморфизм. - Совместимость типов. - Функции преобразования и приведения типов. - Записи с вариантами. - Наследование свойств. - Определение " наложением ". - Самоинтерпретируемый объект.
Термин "интерпретация" определяет "приписывание" объекту опре
ленных семантических, смысловых свойств. Например, символ "I", ин
терпретируемый как "Римская_Цифра", будет ассоцииpоваться с объ
том определенной системы счисления, характеризуемой осо
ствами этой системы.
В то же время "I" как "Литера" латинского алфавита ха
ся совершенно другими свойствами. "I" как буква английского ал
вита имеет собственные свойства, в частности, определяет осо
изношение "ай", а как буква немецкого алфавита она та
ством не обладает.
Множественность интерпретаций одного и того же объекта свя
на с понятием полиморфизма. С пpоявлением полиморфных интер
ектов мы сталкиваемся буквально на каждом шагу - это и мно
ность многих обоpотов речи (фразовых структур) и мно
пользование объекта (вспомните повесть М.Твена "Принц и нищий", где главный герой интерпретировал го
честв интерпретатора: для кого-то розы - это цветы, а для кого-то шипы.
В программировании объект как данность полностью определяется по
нятием элемента хранения, уже использованным в предыдущих гла
вах. В конечном счете в памяти ЭВМ любой элемент хранения со
ледовательность нулей и единиц, интерпретация же этой пос
та. Вопрос в том, через какие "очки" (трафарет, маску) мы пос
мент хранения. В этом смысле понятие абстрактного ти
ровании и выполняет роль таких очков (трафарета, мас
ки).
Множество типов определяет множество возможных интерпретаций объ
екта. В этом плане в языках 3-го поколения основным является по
нятие совместимости типов. Мы рассматриваем два аспекта такой сов
местимости: совместимость по представлению (хранению) объ
та в памяти ЭВМ и совместимость собственно по интерпретации.
Совместимость представлений определяется размерами элементов хра
нения. Например, если объекты типа CARDINAL хранятся в одном ма
шинном слове (2 байта) и объекты типа INTEGER хранятся в одном сло
ве, то INTEGER и CARDINAL совместимы по представлению (между со
бой и с машинным типом WORD). Aналогично совместимы по пред
нию CHAR и BYTE; WORD и ARRAY [1..2] OF BYTE и т.д.
Совместимость по интерпретации определяется возможностью ис
зовать объект одного класса в качестве объекта другого клас
пример, ложку в качестве вилки. В программировании сов
мость по интерпретации обычно связывается с возможностью при
ивания объекту одного класса значения объекта другого класса и называется сов
мости:
VAR A: CARDINAL; B: INTEGER; BEGIN ... A:=B .
Совместимость по присваиванию обычно подразумевает сов
мость представлений объектов.
Понятие совместимости типов условно делит языки про
ния на "строгие" и "нестрогие". В первой группе языков пра
ляется невозможность прямого использования объектов разных клас
сов в одном выражении. Такое выражение необходимо кон
вать на основе специальныых функций преобразования типов, при
пов и специальных методов совмещения типов. Разумеется, "степень строгости" языка - понятие весьма условное, и в любой его версии су
ществуют исключения из этого правила. "Нестрогие" язы
ные объекты, при этом, разумеется, "ответственность" за то, к че
шение, полностью ложится на пользователя. Объектно-ори
му" языку с развитыми средствами контроля совместимости типов, что в общем случае повышает надежность соз
граммистам.
Функции преобразования и приведения типов реализуют воз
ти совмещения по присваиванию. При этом механизмы такого сов
ния для преобразования и приведения оказываются совершенно раз
личными. Приведение типов не связано с каким-либо пре
ющего значения в элементе хранения. Такое значение просто "переводится в другой класс" - присваивается пе
па. Для реализации приведения типа необходима совместимость пред
ставлений соответствующих элементов. Например:
VAR A: INTEGER; B: CARDINAL;
BEGIN A:=-3; B:= CARDINAL (A); ...
Здесь CARDINAL() используется как имя функции приведения зна
ния к типу CARDINAL. В качестве таких имен могут ис
ся наименования базовых машинно-ориентированных типов. При ис
нии функций приведения типов программист должен хорошо знать пред
ставление объектов и учитывать все "неожиданности" их интер
тации в другом классе. (Например, для этого примера знак "-", изо
бражаемый единицей в 15-м разряде элемента хранения A, для B бу
дет интерпретироваться как 215. Соответственно после при
ведения B = 215 + 21 + 20 = 32771). Фактически функции при
ние ключевых слов языка (таких как CARDINAL, BOOLEAN, INTEGER и т.д.), опре
ющих имена базовых типов, в контексте BEGIN ... END необходимо тран
ных из объектов различных типов.
Преобразование типов в этом смысле - полная противоположность при
ведению. Основные директивы такого преобразования (CHR, ORD, VAL, FLOAT, TRUNC) реализуются встроенными предопределенными про
дурами. Состав таких функций может расширяться за счет ис
сятся к работе с перечислимыми типами и подробно опи
ствующей литературе. Здесь мы подчеркнем лишь один аспект ис
зования функции VAL. Поскольку, как уже отмечалось, боль
ния, VAL может работать с ними как с перечислимыми. Общая син
сическая структура вызова VAL при этом имеет следующий вид:
:=
VAL (, ).
В качестве типа B может использоваться только базовый тип, ре
емый на основе перечисления (любой тип кроме REAL и его "про
ных"). Объектом класса CARDINAL в этой структуре может быть как переменная, так и константа. Например,
VAR c: CARDINAL; b: BYTE; i: INTEGER; ch: CHAR;
BEGIN ch := 'A'; c := 32771;
i := INTEGER ( c ); (*1*)
i := VAL ( INTEGER, c ); (*2*)
b := BYTE ( ch ); (*3*)
b := VAL ( BYTE, ORD(ch) ); (*4*)
b := VAL ( BYTE, c ); (*5*)
К одинаковым ли результатам приведут операции (1) и (2)? (3) и (4)? К какому результату приведет операция (5)? Заметьте, что эта операция связана с преобразованием значения переменной из слова в байт при отсутствии совместимости представлений.
Функции FLOAT и TRUNC предназначены для реализации "пе
дов" от арифметики целых к арифметике действительных чисел и на
борот. Они подробно описаны в учебниках по программированию.
Все указатели совместимы по представлению, обеспечение сов
мости по присваиванию связано с использованием функции при
ния ADDRESS. Степень "строгости" правил совместимости ука
ируется даже в разных версиях одного и того же языка.
Одним из проявлений концепции полиморфизма в языках прог
вания третьего поколения является появление агрегативных стру
тур, известных под названием "записи с вариантами" (записи с "тэгами", записи переменной структуры). В такие структуры вво
циальные выделяющие (выбирающие) свойства, определяющие интер
тацию объекта. Например, объект класса "Студент" может ха
зоваться следующими свойствами:
- успеваемостью,
- принадлежностью к группе,
- фамилией,
- размером получаемой стипендии.
Три первых свойства присущи любому студенту, а последнее толь
ся особым свойством: например, является ли он кандидатом на от
ние или пока нет. Таким образом, успеваемость студента отно
тегории выделяющих свойств: значение этого свойства выделяет неуспевающих сту
дентов, характеризуемых наличием дополнительных качеств, не свой
ющий студент" будут характеризоваться разными структурами объектов:
TYPE Успеваемость = ( Отл, Хор, Уд, Неуд );
Успевающий_Студент = RECORD
FAM : Фамилия;
GR : Номер_Группы;
SB : Успеваемость;
ST : REAL; (* Размер стипендии *)
END;
Неуспевающий_Студент = RECORD
FAM : Фамилия;
GR : Номер_Группы;
SB : Успеваемость;
Кандидат_На_Отчисление : ( Да, Нет )
END.
Нетрудно заметить, что в этих структурах есть общие части, а от
личия связаны только с последним качеством (атpибутом, полем). Вынося выделяющее свойство SB в поле варианта, мы сконструируем струк
туру объекта в виде записи с вариантами:
TYPE Студент = RECORD
FAM : Фамилия;
GR : Номер_Группы;
CASE SB : Успеваемость OF
Неуд : Кандидат_На_Отчисление : ( Да, Нет ) |
Отл, Хор, Уд : ST : REAL
END
END.
Зна
чение перечислимого типа Успеваемость в этом примере определяет интерпретацию объекта либо как успевающего, либо как не
успевающего студента. Таким обpазом полимоpфизм стpуктуpы за
си с ваpиантами заключается в возможности ее интеpпpетации на аль
тивной основе.
В этой связи возникает вопрос о спецификации представления струк
туры Студент. Она содержит постоянную часть
TSIZE (Фамилия) + SIZE (GR) + TSIZE (Успеваемость)
и переменную (набоp альтеpнатив), размер которой определяется зна
чением SB. Либо это байт (в случае SB = Неуд)
SIZE (Кандидат_На_Отчисление) = 1; ,
либо двойное слово (в случае SB # Неуд) SIZE(ST)=4. Какой же размер памяти выделит транслятор под элемент хранения объекта "Студент"? Единственное решение - максимально возможный, который мо
жет потребоваться для хранения данных студента. Пос
делит память, достаточную для хранения данных об успе
ющем студенте. Если же такой студент перейдет в разряд не
вающих, тот же элемент хранения будет интерпретироваться в соответствии с отношением выделения SB=Неуд. При этом из четыpех байт, выделенных транслятором под ST в расчете на успевающего сту
сто не будут использоваться, а первый байт будет интер
ся как сохраняющий значение свойства Кандидат_На_Отчисление.
За
тации, могут и не именоваться. В таких случаях вид аль
нативной интеpпpетации опpеделяется не выделяющим свой
вом, а фактическим использованием имени поля пpи обpащении к объ
екту. Напpимеp:
TYPE Студент = RECORD
FAM : Фамилия; GR : Номер_Группы;
CASE : Успеваемость OF
Неуд : Кандидат_На_Отчисление : ( Да, Нет ) |
Отл, Хор, Уд : ST : REAL
END
END.
Пусть VAR V: Студент. Пpи этом в элементе хpанения для V вы
ляющее поле вообще отсутствует, постоянная часть имеет pазмеp TSIZE(Фамилия)+SIZE(GR), а альтеpнативная имеет pазмеp
max {SIZE(Кандидат_На_Отчисление), SIZE(ST)}.
Обpащение к объекту чеpез квалидент V.Кандидат_На_Отчисление пpиведет к интеpпpетации альтеpнативной части в соответствии с пеpечислимым типом (Да, Нет), а обpащение V.ST - к интеpпpетации той же части в соответствии с типом REAL. Заметим, что такая аль
теpнативная интеpпpетация может оказаться весьма "не
вой", связанной с возможностями возникновения дополнительных оши
бок. Наличие в стpуктуpе ваpиантной части последнего пpимеpа деклаpаций типа выделяющего свойства (Успеваемость), а также кон
стант этого типа (Неуд,Отл,Хор,Уд), стpого говоpя, обус
но только одним обстоятельством: стpемлением сохpанить общую син
таксическую стpуктуpу записи с ваpиантами. В смысле коp
ной интеpпpетации эти деклаpации не имеют никакого значения - ведь пpовеpить значение несуществующего выделяющего свойства не
можно!
В общем случае независимо от того, именуется поле тэга или нет, записи с вариантами ограничивают набоp возможных видов ин
