Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

12.1. ОБЪЕКТЫ

715

(12.1) можно выразить формулой:

CRoleOfActor



CActor

(12.2)

Класс-наследник может переопределить любое имя из класса-предка (точ-

но так же,как модуль может переопределить любое имя из используемого мо-

дуля, а внутренний блок — имя из объемлющего). Если нет дополнительных

спецификаций, то новое имя просто экранирует старое (и, таким образом, в

памяти компьютера они оба сосуществуют).

Любой наследник может быть использован там, где правила синтаксиса

требуют его предка. Так что объектно-ориентированное программирование

вводит новое приведение данных: приведение наследника к типу предка.Оно,

в частности, производится при присваивании

TheActor := TheRoleOfActor;

(12.3)

где

TheActor

— конкретный объект класса

CActor

Внимание!

В большинстве книг по ООП используется квазинаучная и

вводящая в заблуждение терминология,когда наследник объявля-

ется ‘подтипом’ или ‘конкретизацией’ предка. С точки зрения ал-

гебраических систем наследник является обогащением сигнату-

ры предка и его надмоделью, а вовсе не конкретизацией. А если

учесть, что

смысл

функций при этом не обязан сохраняться,то от-

ношения между ними еще слабее и практически полностью про-

тивоположны тем, на которые намекает общепринятая термино-

логия.

Если переопределенный в наследнике метод не имел дополнительной спе-

цификации

virtual

, то он экранирован новым методом, но при приведении

наследника к типу предка старый метод всплывает наружу и используется в

вызовах. Такой метод называется статическим. Обработка статических ме-

тодов трансляторами и вызов их в ходе исполнения программы не отличают-

ся принципиально от работы с обычными процедурами. Здесь по-прежнему

осуществляется статическое связвание имени с именуемой им сущностью.

Если же он имеет эту спецификацию, то он называется виртуальным ме-

тодом и может быть вытеснен новым методом в случае, если новый метод

задан со спецификацией

override

. Таким образом, при присваивании значе-

ния переменной объектного типа происходят неявные и согласованные при-

сваивания новых значений некоторым виртуальным методам предков.

716

ГЛАВА 12. ООП

При вызове виртуального метода сначала вычисляется связь между име-

нем и методом для данного конкретного экземпляра объекта (как говорят,

сущность и имя связаны динамически). При вычислении связи используется

информация о типе конкретного экземпляра, и, таким образом, информация

о типах объектных значений частично сохраняется в программе. В объект-

но-ориентированных языках есть способы работы с такой информацией, со-

ответствующие переменные имеют типом (имена) классов, конкретный тип

значения вычисляют функции, подобные

ClassOf

Сам вызов представляется косвенной ссылкой, которая по типу значения

находит адрес традиционного вызова нужного в данный момент метода. Ко-

нечно же, абстрактно-синтаксическое представление вызова метода при ди-

намическом связывании становится другим (упражнение 1). Механизм дина-

мического связывания был создан и достаточно хорошо реализован еще на

заре объектно-ориентированного программирования в языке

Simula 67

Единственной возможностью проимитировать динамическое связывание

в языке со статическими связями имен и значений является буквальное по-

вторение в нескольких классах всех нужных процедур.

В связи с возможностью замены методов целесообразно иметь возмож-

ность указания, что данный объект либо метод не подлежит переписыванию

и экранированию у наследников, что он является конечным:выполняет завер-

шенную функцию, которую можно считать системной для данной библио-

теки классов. Такая спецификация

ﬁnal

имеется из рассматриваемых нами

лишь в языке

Java

Пример 12.1.1. При моделировании программирования от состояний в рам-

ках ООП (статический автомат) чаще всего целесообразно описать все со-

стояния как классы, являющиеся наследником одного и того же класса, на-

пример,

CState

. В этом классе целесообразно описать общие данные всех

состояний, а также метод, применяемый для исполнения действия, сопоста-

вленного состоянию,и для перехода к новому состоянию.Первый из этих ме-

тодов должен заменяться в каждом конкретном состоянии, а второй должен

быть финальным (если не формально, то фактически). Получается примерно

следующее описание.

CState={abstract} class(TObject)

NextState: CState;

ExecResult: Condition;

CommonData: Data;

procedure Execute; {abstract}

12.1. ОБЪЕКТЫ

717

function CState.Transfer: CState; {ﬁnal}

begin

...

result NextState

end;

Заметим, что процедура

Execute

не должна иметь реализацию. Она долж-

на быть переписана в наследниках этого класса. Насчет

Transfer

ситуация

противоположная: она должна быть описана при реализации класса

CState

либо унаследована им от его предков.

После такого описания тело цикла моделирования конечного автомата

имеет примерно следующий вид

while true do begin

State.Execute;

Next:=State.Transfer; if Next<> nil then State:=Next else Leave;

end;

Заметим,что поскольку состояние у нас именуется переменной типа

CState

возможное переписывание функции

Transfer

ни на что не влияет: будет вы-

зван ее исходный вариант. Но, особенно если тип

CState

скрыт глубоко вну-

три библиотеки моделирования, программист порою может быть весьма уди-

влен, почему это переписанный им метод не работает? Каждый из авторов не

раз наблюдал эту ситуацию и на своей, и на чужой практике. Так что явная

спецификация

ﬁnal

, которая выдаст ошибку еще на этапе компиляции, явля-

ется полезной.

Конец примера 12.1.1.

Рассмотренный пример приводит к важному понятию абстрактного клас-

са. Это класс, некоторые из методов которого должны быть переписаны в

его наследниках, перед тем, как вызываться. У нас таким методом являет-

ся

Execute

. Во всех современных системах ООП предусмотрено понятие аб-

страктного класса и спецификация методов как абстрактных.

Рассмотрим соотношение между абстрактными классами и абстрактны-

ми представлениями данных, описанными в п. 11.4.2.При абстрактном пред-

ставлении некоторые методы задаются достаточно грубо. По сути дела они

должны быть переписаны в ходе реализации. Но они не являются просто пу-

стыми затычками, они могут быть использованы для отладки программы и

718

ГЛАВА 12. ООП

часто могут оставаться на ходу вплоть до самых последних этапов разработ-

ки первой версии программы, да и в дальнейшем быть аварийной возмож-

ностью работы при отладке ошибок в интерфейсе или в конкретном пред-

ставлении.Спецификаций,обеспечивающих описание абстрактных предста-

влений, в современных широко используемых языках нет.

Тем не менее абстрактные классы обеспечивают здесь некоторый прак-

тически полезный суррогат. Абстрактное и конкретное представление могут

быть определены как два наследника абстрактного класса, служащего в дан-

ном случае просто общей сигнатурой понятий. Переход от программы, ра-

ботающей с абстрактным представлением, к программе, работающей с кон-

кретным, может быть осуществлен всего одной заменой описания типа, по-

добного

typedef Concept_Realization = Abstract_Realization;

заменить на

typedef Concept_Realization = Concrete_Realization;

Заметим, что сделать конкретную реализацию потомком абстрактной ни-

чем не облегчает задачу.

Тот факт, что в языках

C++

Java

происходит привязка некоторых функ-

ций к заранее фиксированным именам, превращает в необходимость поли-

морфизм функций, создававшийся в

С++

скорее всего без всякой задней мы-

сли, просто для облегчения неаккуратного программирования или для фор-

мального инкорпорирования в язык того, что неплохо зарекомендовало себя

в других местах, например, в

Simula 67

. В частности, конструкторы имеют

имя класса, но конструкторов часто нужно много для разных нужд. Точно так

же и с деструкторами. По аналогии и для достижения общей согласованно-

сти интерфейсов

элементы полиморфизма проникли в

Object Pascal

, но там

они не являются чем-то необходимым.

12.1.3. Множественное наследование и интерфейсы

Глядя на приведенный в (12.1) заголовок класса, сразу возникает соблазн

Все равно достичь ее не удалось,так что попытки в этом направлении были бесплодными!

12.1. ОБЪЕКТЫ

719

определить новый класс приблизительно следующим образом:

/* C++ */

class CRoleOfActor:: CActor,CRole,CState,CAnimation

{ Тело описания класса }

(12.4)

Это означает, что новый класс

CRoleOfActor

является наследником сразу че-

тырех ранее определенных классов:

CActor, CRole, CState, CAnimation

, а все

они — его предками. Математический смысл (12.4) можно выразить следу-

ющей системой формул:

CRoleOfActor



CActor

CRoleOfActor



CRole

CRoleOfActor



CState

CRoleOfActor



CAnimation

(12.5)

Так что возможны все присваивания вида

TheActor := TheRoleOfActor;

TheRole := TheRoleOfActor;

TheState := TheRoleOfActor;

TheAnimation := TheRoleOfActor;

(12.6)

где

TheState

— конкретный объект класса

CState

и т. п. Наследник включает

все данные и все методы предков. Никакой попытки согласования данных и

методов разных предков в нынешнем ООП не делается. Они просто свали-

ваются в одну кучу, а если возникают конфликты имен, программист должен

специфицировать, к какому из предков относится имя, например:

TheMainLover::CRole::face

или

TheMainLover::CActor::face

Есть один момент, который представляет ценность в исключительно пло-

хо (даже по меркам

С++

) продуманном механизме множественного насле-

дования. Часто нам целесообразно установить, что у нескольких типов, на

которые опирается потомок, есть общая часть. Именно возможность устано-

вления этой согласованной общей части была бы ценной в множественном

наследовании, но, как известно в теории абстрактных типов данных, задача

согласования частей исключительно трудна и с теоретической, и с практиче-

ской точки зрения. В

С++

имеется обходной путь, который позволяет задать

эту возможность.

720

ГЛАВА 12. ООП

Спецификатор

virtual

в языке

C++

может быть применен также к предку

в описании непосредственного потомка. Он имеет смысл лишь тогда, когда

несколько потомков данного класса в дальнейшем будут иметь общего на-

следника. Это единственный способ объявить в

C++

, что некоторые части

предков отождествляются у наследника, а именно, все наследники данного

класса и других классов, также объявивших этот класс виртуальным, будут

пользоваться общим экземпляром виртуального класса. Рассмотрим пример.

class CActor:: CPerson, virtual CFace {...};

class CAnimation: CView, virtual CFace {...};

Здесь объект, представляющий лицо актера,один и тот же и внутри

CPerson

и внутри

CView

. Если бы хоть в одном случае

virtual

было бы опущено, лица

были бы разные.

В связи с несогласованностью и конфликтами смыслов при наследова-

нии, наследование одним потомком сразу от нескольких предков никуда, кро-

ме

C++

, не проникло, и правила хорошего тона требуют, чтобы везде, где воз-

можно, у класса был бы один непосредственный предок. Но объективная по-

требность наследования операций сразу нескольких предшественников есть,

значит, нужно разобраться в том, что на самом деле нужно наследовать.

Конечно же, наследовать все данные всех предков — лобовое, и, как все-

гда бывает, самое тупое решение, складывающее в кучу все недостатки и тем

самым почти уничтожающее достоинства. На самом деле нам нужно иметь

возможность обращаться к новому классу, как к другим, ранее определен-

ным. Поэтому во многих системах middleware и в языке

Java

было введе-

но понятие интерфейса, которое сразу же было воспринято языком

Object

Pascal

. Нам важно иметь возможность обращаться к данному объекту как к

нескольким другим, и интерфейс фиксирует методы (а в языке

Java

и данные,

так что понятия интерфейса

Java

Object Pascal

не полностью совместимы),

которые должны быть предоставлены классом для обращения в соответствии

с данным интерфейсом. Пример интерфейса в языке

Object Pascal

type

IMalloc = interface(IInterface)

[’{00000002-0000-0000-C000-000000000046}’]

function Alloc(Size: Integer): Pointer; stdcall;

function Realloc(P: Pointer; Size: Integer): Pointer; stdcall;

procedure Free(P: Pointer); stdcall;

12.1. ОБЪЕКТЫ

721

function GetSize(P: Pointer): Integer; stdcall;

function DidAlloc(P: Pointer): Integer; stdcall;

procedure HeapMinimize; stdcall;

end;

Первая, самая загадочно выглядящая, строка в описании интерфейса за-

дает его идентификацию для систем

middleware

и может быть опущена. Сле-

дующие строки задают методы (в

Java

также и константы) интерфейса. Все

они внутри интерфейса абстрактные, они должны быть реализованы в объ-

ектах, допускающих доступ по данному интерфейсу.

Поэтому конструкции, аналогичные (12.4), в

Object Pascal

Java

записы-

ваются следующим образом:

{Object Pascal}

type

CRoleOfActor = class(CRole,IActor,IState,IAnimation)

...

end;

/* Java*/

class CRoleOfActor extends CRole implements IActor,IState,IAnimation;

{...};

Заметим, что возникают те же самые проблемы с двусмысленностью, что

и при множественном наследовании в

C++

. Способы их разрешения в

Java

Object Pascal

умилительно расходятся. В

Java

сигнала ошибки не выдает-

ся, Вы можете пользоваться несовместимыми интерфейсами, но если Ваша

программа будет иметь глупость обратиться к неоднозначно понимаемому

методу или константе, произойдет ошибка. В

Object Pascal

Вы можете про-

сто назвать по-другому метод, примененный для реализации объявленного в

интерфейсе:

function IActor.Visualize = DrawFace;

procedure IAnimation.Visualize = PlayAnimation;

Решение, включающее интерфейсы, не дает возможности отождествить

подобъекты интерфейсов, но это и не нужно: ведь теперь не предки предо-

ставляют свои объекты и методы потомку, а, наоборот, все интерфейсы ссы-

лаются на один и тот же реализующий их объект, который и поддерживает

единство данных.

722

ГЛАВА 12. ООП

В спецификациях поведения объекта, которые по сути своей определяют

его как единицу декомпозиции,может встретиться,к примеру, следующее со-

всем непроцедурное утверждение. Объект не должен у себя реализовывать

требуемое от него действие (т. е. в его классе и в классах его прародителей

не будет подходящего метода), т. к. есть другой объект, умеющий это делать,

которому первый объект делегирует полномочия выполнять требуемое дей-

ствие. Реализация так специфицированного поведения может быть выполне-

на путем задания атрибута-ссылки на другой объект и косвенного обращения

к его методу. Т. е. в операционном аспекте обычная процедурность сохра-

няется, правда, дополненная ссылочными связями. Делегирование — один

из примеров того, как в объектном стиле подменяется традиционная про-

цедурная декомпозиция новыми понятиями. Подобные способы объектной

декомпозиции, которые образуют набор технологических шаблонов (паттер-

нов) проектирования, изучаются специально в рамках курсов объектно-ори-

ентированного проектирования. С точки зрения обсуждения языковых аспек-

тов стоит отметить, что специальные конструкции для подобных шаблонов в

языках программирования не предлагаются. Сегодня они рассматриваются

лишь как типовые приемы программирования и задаются стандартными для

операционных языков средствами. Тем не менее, как было показано, шабло-

ны проектирования существенно отходят от традиционной процедурности

как основы декомпозиции программ. Иными словами, расширяется понятие

процедуры, и это расширение неизбежно должно оказать влияние и на базис.

§ 12.2. ОБЪЕКТНАЯ МОДУЛЬНОСТЬ

В данном разделе рассматривается, как средства объектно-ориентирован-

ного программирования сочетаются с модуляризацией программ, и в каком

направлении идет их развитие. Для этой цели лучше всего подходит линия

развития

TURBO

Delphi

(

ObjectPascal

)языка

Pascal

.Изложение иллюстри-

руется на модификации демонстрационного примера из § 8.6.3.

Первый объектно-ориентированный диалект

Pascal

’я в линии

TURBO

—

TURBO Pascal

версии 5.5. Он предлагает программисту лишь минимально

необходимые средства поддержки данного стиля. Как и в последующих вер-

сиях языка, задача объектной модуляризации решается на основе модульно-

сти версии

TURBO Pascal

’я 5.0, рассмотренной в предыдущем разделе. Но

новые средства дают и новые возможности. В частности, появляется под-

держка рассмотрения представления (в примере — массив

Container

; пере-

12.2. ОБЪЕКТНАЯ МОДУЛЬНОСТЬ

723

менные

, связанные с алгоритмом кольцевого буфера, мы пока будем

считать частью реализации) отдельно от реализации. Теперь можно вовсе не

знать, является

Container

массивом или чем-то иным, — методы работы с

этим объектом, описанные в отдельном модуле, обеспечивают реализацию

всем необходимым. Более того, мы можем рассматривать такие

Container

’ы,

которые в состоянии принимать на хранение объекты разных типов, даже

не зная того, каким способом это достигается. Тем самым решается пробле-

ма реализации очереди с содержимым разных типов.

Сама очередь стано-

вится объектом-наследником от

Container

’а. Как следствие, методы работы

с этим объектом оказываются и методами объектов очередь. Для реализации

очереди, как кольцевого буфера нужны переменные

BFull

BEmpty

рассмотрение которых совместно с

Container

’ом выделяет очередь как са-

мостоятельную структуру данных. В новой ситуации естественно задавать

MaxSize

не константой, а атрибутом конкретного экземпляра очереди. Кро-

ме того необходимо решение вопроса об элементе, который предъявляется в

ошибочной ситуации, когда делается попытка чтения из пустой очереди, т. е.

о значении

NotEl

. Оно должно быть не целочисленной константой, а каким-

то выделенным значением одного из типов содержимого

Container

. Без све-

дений о конкретных очередях узнать их выделенные элементы невозможно,

значит, определение

NotEl

, как и

MaxSize

, нужно возложить на инициализа-

цию очереди. В результате представление очереди определено более точно:

это

Container

BFull

BEmpty

MaxSize

NotEl

Для независимого от реализации понимания очереди в объектном стиле

нужно декларировать методы для работы с объектами конструируемого типа.

Это те же процедуры

PutElQueue

GetElQueue

StateQueue

, которые были

представлены в первой реализации, а также новая процедура (со старым име-

нем)

InitQueue

, дополнительные действия которой — установка для

MaxSize

значения, передаваемого через параметр, генерация представляющего оче-

редь объекта типа

Container

и определение

NotEl

. После окончания работы с

экземпляром очереди этот экземпляр должен быть уничтожен, соответствен-

но, появляется еще метод-деструктор

DoneQueue

Еще одно проектное решение, которое нужно принять, касается проце-

Словосочетание «разные типы» понимается здесь как возможность одновременного на-

личия в очереди объектов различных классов. Если мы захотим иметь общую реализацию

для очередей «разных типов» с содержимым одного типа, то для этого придется воспользо-

ваться более развитыми объектно-ориентированными средствами, чем необходимо для по-

яснения модуляризации.

724

ГЛАВА 12. ООП

дуры

IncI

. Это служебная процедура, осуществляющая “закольцовывание”

буфера с помощью манипулирования индексом. Если оставить ее в прежнем

виде, то она становится методом конструируемого типа объектов, т. к. ее ал-

горитм зависит от атрибута объекта

MaxSize

. В то же время, предоставлять

IncI

на уровне использования не нужно. В

TURBOPascal

’е версии 5.5 средств

разграничения предоставляемых и служебных методов не предусмотрено, а

значит, придется специально сообщать пользователю модуля об этих особен-

ностях реализации. Более того, в этом языке нет средств оградить пользова-

теля модуля от прямого обращения к атрибутам объектов. В качестве аль-

тернативы в данном конкретном случае уместно указать на возможность вы-

несения процедуры

IncI

на уровень общих средств модуля, представленных

в разделе реализации, а значит, доступных только в данном модуле. Зави-

симость этой процедуры от контекста сводится к использованию атрибута

MaxSize

экземпляра очереди, который можно передавать через дополнитель-

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

В дальнейшем мы реализовываем первый вариант работы с

IncI

С учетом сказанного следующий фрагмент модуля

AllQueue_5_5

нужда-

ется только в одном пояснении.Мы определяем два типа для описания объек-

тов-очередей:

Tqueue

Pqueue

. Первый из них задает структуру всех экзем-

пляров очереди, а второй — тип указателей на нее. Смысл такого (практи-

чески стандартного в ООП) построения в том, что с объектными значени-

ями намного удобнее работать, когда отведение памяти для них не регули-

руется стековым механизмом. Пока можно считать, что принятое решение

диктуется особенностями реализации объектного типа

Container

в модуле

ContainerUnit

, который подключается к модулю

AllQueue_5_5

в разделе uses.

Программа 12.2.1

unit AllQueue_5_5;

interface

uses ContainerUnit; {

модуль, предоставляющий средства

}

{

хранения объектов разной природы

}

type States = ( Full, Empty, Normal );

Pqueue = ^Tqueue;

Tqueue = object ( Container );

MaxSize,

IB,

IE : Integer;

BFull,