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

Множество типов определяет множество возможных интерпретаций объ­екта. В этом плане в языках 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) реализуются встроенными предопределенными про­­це­дурами. Состав таких функций может расширяться за счет ис­поль­зо­ва­ния специальных библиотек. Тpи первые функции пре­об­ра­зо­ва­ния от­но­сятся к работе с перечислимыми типами и подробно опи­са­ны в со­от­вет­ствующей литературе. Здесь мы подчеркнем лишь один аспект ис­поль­зования функции VAL. Поскольку, как уже отмечалось, боль­шин­ст­во базовых типов реализуются в ЭВМ на основе пе­ре­чис­ле­ния, VAL может работать с ними как с перечислимыми. Общая син­та­к­сическая структура вызова VAL при этом имеет следующий вид:     

      <Имя переменной типа B> :=  
                  VAL (<Имя типа B>, <Объект класса CARDINAL>). 

В качестве типа 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етации на аль­­теp­на­тивной основе.

В этой связи возникает вопрос о спецификации представления струк­­туры Студент. Она содержит постоянную часть

    TSIZE (Фамилия) + SIZE (GR) + TSIZE (Успеваемость)

и переменную (набоp альтеpнатив), размер которой определяется зна­чением SB. Либо это байт (в случае SB = Неуд)

        SIZE (Кандидат_На_Отчисление) = 1; ,

 либо двойное слово (в случае SB # Неуд) SIZE(ST)=4. Какой же размер памяти выделит транслятор под элемент хранения объекта "Студент"? Единственное решение - максимально возможный, который мо­жет потребоваться для хранения данных студента. Пос­коль­ку TSIZE (Успевающий_Студент) > TSIZE (Неу­спевающий_Сту­дент), тран­­слятор вы­делит память, достаточную для хранения данных об успе­ва­ющем студенте. Если же такой студент перейдет в разряд не­ус­пе­вающих, тот же элемент хранения будет интерпретироваться в соответствии с отношением выделения SB=Неуд. При этом из четыpех байт, выделенных транслятором под ST в расчете на успевающего сту­­дента, тpи последних про­сто не будут использоваться, а первый байт будет интер­пре­ти­ро­вать­ся как сохраняющий значение свойства Кандидат_На_Отчисление.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11