Быстрый поиск

Реферат: Программирование, ориентированное на объекты

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