В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 77

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 77)

50); { начальный радиус - 50 точек растра }

AnArc.Init(151, 82, { Начальные координаты центра - 151, 82; }

25, 0, 90);{ начальный радиус - 50 точек растра }

{ Нач. угол: 0; Кон. угол: 90 }

{ Замените AnArc на ACircle, чтобы перемещать окружности вместо дуг.

Нажмите клавишу "исполнение" (Enter) чтобы прекратить перемещения (и

завершить программу) }

AnArc.Drag(5); { Устанавливается шаг перемещения }

(* при нажатии соответствующих клавиш-стрелок дуга (или окружность)

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

CloseGraph;

RestoreCRTMode;

end.

Итак, если бы не виртуальные операции, то не удалось бы

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

Виртуальные операции, определенные для дуг, всюду перекрывают виртуальные

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

окружностей. Ради последнего огород и городился!

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

объявлении объектного типа, так и во всех его обогащениях - коллизии имен

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

разрешено только при замене виртуальных операций при обогащении объектного

типа. (Профили всех одноименных виртуальных операций должны совпадать!

Сравните с Адой и примером в Обероне).

Тем самым становится особо важным давать атрибутам объекта имена,

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

возможности во всех мыслимых ее развитиях - ведь эти имена становятся

"ключевыми параметрами" развития программы.

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

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

трансляции определяющего этот тип модуля). Для виртуальных операций

применяется так называемое отложенное (задержанное) связывание с их именами.

Это связывание при объявлении обогащенного типа, незавершенное при

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

требующее завершения при трансляции или исполнении определяющего модуля для

обогащенного типа - в Турбо Паскале выполняется посредством ТВО.

Заметим, что обычно атрибуты-поля не относят к абстрактным атрибутам.

Однако классификация атрибутов по степени их настраиваемости (конкретные,

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

единого взгляда на абстракцию-конкретизацию в ЯП (в частности, выделение

абстракции связывания), но и предсказать появление в перспективе ЯП, где

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

экземпляра, и даже с точностью до конкретного исполнения экземпляра. Мы

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

уже продемонстрирован примером в Обероне.

[С другой стороны, фактически и сейчас применяется оптимизация

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

обращений с виртуальными правилами, не помещается ссылка на ТВО. Нетрудно

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

динамически через ТВО, а прямой ссылкой на тело правила, настроенного на

конкретный экземпляр объекта. Такая настройка может быть оправдана

многократным выигрышем в скорости за счет систематической специализации тела

операции по всем правилам конкретизирующего программирования.]

19.5. Критерий Дейкстры

В свое время Дейкстра, размышляя о том, какие процедуры следует

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

пришел к выводу, что выделять следует ИСКЛЮЧЕНИЯ из общего правила,

достойные оптимизации (т.е. процедуры НЕрекурсивные). Другими словами, если

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

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

значениях параметров, то последний обязан считать ее (потенциально)

рекурсивной и соответственно транслировать (возможно, менее эффективно, чем

в нерекурсивном случае).

При таком решении автора ЯП, с одной стороны, усилия программиста

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

на формирование некоторого ЗАПРЕТА (на использование определяемого

программного объекта), имеющего целью экономию машинных ресурсов. Когда же

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

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

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

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

отвлекает внимание программиста на проблемы оптимизации от существенно более

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

выбора для автора ЯП критерием Дейкстры. Этот критерий становится все более

актуальным по мере роста цены живого труда по сравнению с ценой машинных

ресурсов.

К сожалению, авторы ЯП Турбо Паскаль 5.5 не учли критерия Дейкстры (или

не стали им руководствоваться), когда решили выделять ключевым словом

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

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

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

own). Достаточно взглянуть на объявления типов Points и Circle, которые

пестрят словом virtual, чтобы усомниться в том, что авторы поступили удачно.

А если вспомнить, что программист, не написавший этого сакраментального

слова, ограничивает развиваемость (а следовательно, и тиражируемость) своей

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

может быть обнаружена только через годы эксплуатации программы (когда

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

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

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

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

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

невозможно - работает принцип консерватизма языковых ниш. Оцените глубину

критерия Дейкстры!

19.6. Объекты и классы в ЯП Симула-67

Уместно вспомнить здесь о Симуле-67 как первом объектно-ориентированном

ЯП [35,36]. Поразительно, сколь точно авторы этого классического ЯП угадали

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

рассмотренных понятий из самых современных ЯП и понятий Симулы-67. Для

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

Действительно, с-классы - это типы объектов с квазидинамическим

контролем (контроль по квалификации с-ссылок, т.е. типу указателей). Объект

- это с-класс (возможно , со своим квазипараллельным исполнением, т.е. с-

открепленный). Обогащение (наследование) - это определение с-подкласса с

дополнительными атрибутами. При этом старые операции применимы к новым

объектам и присваивания "старым" с-ссылкам новых объектов вззможно (но не

наоборот) - это управляется квалификацией с-ссылок (как уже отмечено, аналог

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

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

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

ссылка является ссылкой на потомка (имеет право)).

С-управление видимостью развито удивительно для классического ЯП,

непосредственно наследовавшего блочную идеологию Алгола-60, и неплохо

обслуживает объектную ориентацию языка (хотя, конечно, не учитывает

модульности, которой в эталонном языке нет).

С-операции - это активные атрибуты с-объектов и действуют они "в рамках

с-объектов" (т.е. сами доступны (из других объектов!) только через ссылку на

с-объект. При этом аргументом операции может служить любая компонента

использующего эту операцию контекста (в соответствии со спецификацией ее

параметров). Если бы еще запретить прямой доступ к "пассивным" атрибутам с-

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

данных (атрибуты-операции с-класса - это и есть операции соответствующего

абстрактного типа данных). Однако в реальной Симуле-67 такие "абстрактные

типы" не защищены от разрушения.

Виртуальные операции - это почти в точности с-виртуальные операции.

Причем и авторы Симулы-67 не учли критерий Дейкстры - с-виртуальные операции

нужно выделять словом virtual.

С-дистанционные идентификаторы аналогичны обычным выборкам по

селекторам. Интересно подчеркнуть, что чем шире область возможных значений

ссылочной переменной (в соответствии с ее квалификацией, т.е. типом), тем

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

иерархии (обогащения) объектов. Однако в Симуле-67 можно снять запрет на

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

родительского к потомку) за счет явной разрешающей "оперативной"

квалификации "qua"

Родитель qua потомок.атрибут_потомка

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

его проще всего поместить в родительский класс (например, для организации в

нем взаимодействия между объектами-потомками из разных классов). Другими

словами, если нельзя, но очень хочется, то можно, но при этом нужно явно

сообщить транслятору о сознательном нарушении запрета. В подобном стиле

действуют и авторы других "строгих" ЯП. Например, в Аде можно обойти

контроль типов, применив "фиктивное" преобразование типов посредством

специально для этой цели предназначенной родовой функции

UNCHECKED_CONVERSION.

Вместе с тем Симула-67 на практике не смогла конкурировать с ЯП, не

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

представлена авторами как "универсальный язык программирования" [#7]. Не

говоря уж о том, что этот ЯП явно опередил свое время - масса программиистов

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

важнейшим его недостатком оказалась относительно низкая эффективность

исполняемых программ.

Дело в том, что в Симуле-67 почти все интерпретируется (это же

характерно и для Смолтока), а не компилируется, как в Турбо Паскале 5.5. В

частности, нет статического создания объектов - они создаются динамически

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

с-ссылок - в общем случае она контролируется динамически). Для относительной

неудачи Симулы-67 сыграло свою роль и полное отсутствие средств

модуляризации (раздельной компиляции) на уровне эталонного языка. В более

современных реализациях они, конечно, имеются (в частности, на отечественных

компьютерах БЭСМ-6 и ЕС [36]). С этой точки зрения ЯП Симула-67 унаследовал

важнейший недостаток своего непосредственного предшественника и подмножества

- Алгола-60, проигравшего Фортрану прежде всего из-за отсутствия модулей.

Кроме того, нет разделения спецификации и реализации. Как уже

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

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

зная структуру программы (а не знать ее не может, так как при отсутствии

разделения спецификации и реализации, а также (в общем случае) раздельной

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

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

соответствующие процедуры. Остается неясным, каким способом (в приведенном

ими объяснении примера на стр.33-34 в [34] имеются противоречия).

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

программирования

Хотя мы рассмотрели далеко не все заслуживающие внимания примеры

современных ЯП (а также аспекты) объектной ориентации, накоплено достаточно

материала для обсуждения открываемых ею перспектив. Среди таких ЯП нужно

назвать по крайней мере Смолток (в особенности Смолток/5 286) и Си++, а

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

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

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

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

операцию этого объекта. Другими словами, каждый объект снабжен

минитранслятором сообщений, устроенным, например, по принципу

Характеристики

Список файлов книги