В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 74
Текст из файла (страница 74)
Действительно, исходным объектам в ее правом нижнем углу соответствуют
обогащенные объекты в левом нижнем углу. Их обогащение проявляется пока
лишь в том, что их просто "больше" - каждому обогащенному соответствует
"бедный".
Наследовать естественно не все операции (возможности, свойства), а лишь
те, которые желательно - поэтому не у всех операций из Q имеются прообразы
в левой части диаграммы. Но если что-то наследуется, то результаты "богатых"
операций для "бедных" должны "сохраняться" - это и отражено в
коммутативности схемы, так как "сохранение" содержательно означает
выполнение для прообразов в P тех же алгебраических законов, что и для их
образов в Q.
Наконец, и требованию защиты от разрушения исходных услуг, сохранению
работоспособности старых программ, пользующихся этими услугами (и косвенно,
отсутствие необходимости в перетрансляции и даже запрет на нее - иначе
окажутся под угрозой старые программы!) - тоже нашлось место в определяющем
гомоморфизм соотношении. Ведь не предполагается какой-либо тождественности P
и Q или их частей. В общем случае годится любое отображение, лишь бы
выполнялось основное соотношение. В частности, допустимо и тождественное
отображение компонент P и Q, когда оно устраивает.
Итак, гомоморфизм из обогащенного типа в исходный - естественное
математическое представление (математическая модель) идеального
наследования. Примеры обогащаемых и обогащенных типов приводились.
Можно добавить еще одну серию примеров. Как известно, программы на ЯП
представляют текстами - последовательностями литер. Будем считать, что
определен исходный тип "Строчка" - последовательность литер. Его обогащение
- тип "Абстрактное_дерево". Объект этого типа представляет собой дерево с
листьями из литер исходной строчки, с доступом к компонентам не только по
номерам литер, но и по селекторам, выбирающим поддеревья. Новое обогащение -
тип "Синтаксический_объект". Одному абстрактному дереву при этом может
соответствовать много синтаксических объектов. Например, одно и то же
абстрактное дерево может играть роль "строка" или "идентификатор" или даже
"буква" (и получить соответствующее значение "синтаксического" атрибута.
Еще одно обогащение - тип "Вхождение_синтаксического-объекта" - одному
идентификатору соответствует несколько его вхождений (в частности,
определяющее и использующие). Обогащаются соответственно и атрибуты.
Например, у вхождения может появиться атрибут "координата", которого не было
у идентификатора. Наконец, другим обогащением синтаксического объекта может
служить так называемое атрибутированное дерево, например, идентификатор с
атрибутами "тип", "область видимости" и др.
Упражнение. Опишите соответствующие обогащения на Обероне. Опишите
также соответствующие гомоморфизмы.
Подсказка. Гомоморфизм
основа: СинтОбъект -> АбстрДерево
с сохранением операции выборка_поддерева_по_селектору, причем
основа(Х.С) = основа(Х).С
где X: СинтОбъект, C: Селектор, "." - операция выборки.
Другие применения гомоморфизма в программировании.
Важно заметить, что понятие гомоморфизма удачно моделирует не только
отношение наследования типов, но и многие другие важнейшие понятия
программирования. Конечно, содержательно все они связаны с тем или иным
представлением о "корректном развитии", "корректном обогащении" ранее
созданного, рассмотренного, изученного и т.п.
Например, метод пошаговой детализации можно считать методом обогащения
ранее рассмотренных структур, при котором к ним оказывается применимым все
более богатый набор операций. Так, начав создавать пакет в Аде пошаговой
детализацией, мы сначала могли лишь переписывать фрагменты программы
("переписать" - первая операция, применимая к структурам-фрагментам), затем
получили возможность транслировать спецификацию пакета (вторая операция),
затем получили возможность исполнять программу (третья операция).
Очевидно и накопление атрибутов при пошаговой детализации. Достаточно
вспомнить уже обсуждавшийся переход от текстов к абстрактным деревьям, затем
к синтаксическим, затем атрибутированным.
Подчеркнем, что всегда существует тривиальный гомоморфизм из одних
структур в другие, отображающий все мыслимые операции в "ничегонеделание".
Мы говорим о естественном гомоморфизме, отражающем содержательное
соответствие всех существенных операций.
Еще один пример гомоморфизма - связь по импорту в Аде, Модуле-2,
Обероне и др. Импортирующий пакет служит областью отправления, а
импортируемый - областью прибытия. Следующий пример - метод экспортного окна
в Обероне. Область отправления - модуль, область прибытия - его
спецификация. Последний из этой серии примеров - отображение состояния,
построенного в результате нахождения очередной согласующей подстановки (в
реляционном программировании) на исходное состояние. Здесь сохраняемые
операции - доступ по именам к значениям.
Какую пользу можно извлечь из изложенных выше соображений?
Во-первых, факт, что казавшиеся совершенно различными понятия
программирования описываются единым математическим понятием, может принести
пользу математической теории ЯП.
Во-вторых, уже сейчас можно классифицировать некоторые языковые
конструкты на "чистые" и "нечистые" с точки зрения идеальной развиваемости в
зависимости от того, описывается ли предлагаемое ими развитие естественным
гомоморфизмом. Назовем соответствующий критерий критерием ЕГМ (ЕГМ-
критерием). Он работает аналогично тому, как левая факторизация
(разделенность) грамматики служит критерием пригодности ЯП для эффективного
анализа.
Конечно, и без ясного понимания или формулировки источника
несообразности во многих случаях интуитивно чувствуется нарушение
естественной регулярности структур или свойств. Критерий ЕГМ позволяет
придать таким оценкам прочную математическую основу.
Например, указатель сокращений "use" в Аде не согласуется с ЕГМ-
критерием (оказывается отступлением от естественного гомоморфизма). Не
согласуется потому, что это не чистая вставка контекста, а вставка с
"фокусами", нарушающими естественное отображение имен используюшего
контекста на имена вставляемого.
Укажем еще один ЕГМ-фильтр: предикаты с побочным эффектом должны быть
отнесены к "нечистым" языковым конструкциям, так как могут "поломать"
уточняемое состояние и тем самым сделать невозможным естественный
гомоморфизм из нового состояния в исходное.
Посредством ЕГМ-критерия легко отделить конкретизацию-обогащение от
конкретизации-специализации (реализуемой, например, универсальным
специализатором). Ведь последней позволительно "ломать" исходные структуры
специализируемой программы и, в отличие от чистой конкретизации-обогащения в
случае специализации может оказаться невозможным естественный гомоморфизм из
новых структур в старые.
Упражнение (повышенной трудности). Опишите точнее все упомянутые
гомоморфизмы или обоснуйте их отсутствие.
Итак, ЕГМ-критерий может оказаться полезным при работе с ЯП, в
особенности с авторской позиции. Другими словами, получен работающий
критерий качества ЯП в целом и отдельных его конструктов.
19. Объектно-ориентированное программирование
19.1. Определяющая потребность
На протяжении всей книги мы неоднократно отмечали потенциальную пользу
от введения активных данных, активных обрабатываемых (и одновременно
обрабатывающих) объектов. Приводились примеры таких объектов, в частности,
объектов задачных типов (процессов) в Аде. Однако активные объекты всегда
обладали некоторой экзотикой, всегда были лишены существенных "прав" обычных
данных, а "обычные" данные - свойств активных объектов.
Например, если пакет в Аде может содержать определения разнообразных
программных услуг и с этой точки зрения может считаться как пассивным, так и
активным объектом, то он не обладает типом, нельзя иметь переменные-пакеты и
т.п. Если задача может определять задачный тип, то в ней нельзя
непосредственно определить никаких услуг, кроме входов; объекты задачного
типа нельзя присваивать (задачные типы считаются ограниченными приватными).
С другой стороны, комбинированные типы в Аде не могут содержать процедур в
качестве компонент.
Для ограничений такого рода находятся свои резоны, однако в целом они
усложняют ЯП, а по закону распространения сложности - и все, что связано с
ним.
Настало время освободиться от неестественных ограничений и подняться на
следующий уровень абстракции - ввести концепцию языкового объекта,
обобщающую представление об активных и пассивных объектах. Конечно, это
фактически означает, что любой объект придется рассматривать как
потенциально активный, если явно не оговорено обратное. Потребность в
концепции подобного рода может показаться надуманной, если не учитывать, что
она непосредственно связана с потребностью овладеть сложностью
программирования, которую лишь частично удовлетворяют все рассмотренные
ранее языковые концепции. Фактически речь идет о потребности рационально
сочетать все их преимущества за счет нового уровня абстракции.
Как мы увидим, эта цель в значительной степени оказалась достижимой на
современном этапе развития программирования в рамках объектно-
ориентированного программирования. Выяснилось, что и другие перспективные
тенденции в сочетании с ним проявляют всю свою мощь и привлекательность.
Иными словами, объектно-ориентированное программирование стало катализатором
нового взрыва творческой активности в области ЯП, первые результаты которого
в виде практичных коммерчески доступных систем программирования уже
появились. Еще более впечатляющие достижения впереди.
Выберем для определенности только один аспект обозначенной нами
определяющей потребности, а именно развиваемость, и покажем путь к объектной
ориентации через стремление к идеалу развиваемости, а затем отметим и иные
перспективы, открываемые объектной ориентацией. Конечно, можно было взять за
основу и иные аспекты определяющей потребности - наш особый интерес к
развиваемости объяснен в предыдущем разделе.
19.2. Ключевые идеи объектно-ориентированного программирования
Первое фундаментальное изобретение, обеспечившее принципиальные
продвижения к идеалу развиваемости, состоит в том, чтобы сделать программный
модуль нормальным языковым объектом (в частности, объектом вполне
определенного типа).
Тем самым в общем случае нормальный языковый объект становится
носителем программных услуг, а управление такими объектами - управлением
предоставляемыми программными услугами, в частности, их развитием и защитой
(ведь программный модуль - это носитель одной или нескольких программных
услуг, предназначенных для совместного санкционированного использования и
защищенных от использования несанкционированного).
Требуемый уровень гибкости в управлении атрибутами программных модулей
(в частности, видимыми в них именами) достигнут уже в таких ЯП, как Ада или
Модула-2. Достигнута определенная гибкость и в управлении типами. Однако из-
за того, что модули не считаются обычными типизированными языковыми
объектами, для модулей и типов нужны два специальных способа управления,
каждый со своими проблемамии, и, главное, с дополнительными проблемами для
программиста. Унификация этих способов управления открывает путь, в
частности, к ясной и гибкой концепции развиваемости.
Однако когда программный модуль становится объектом некоторого типа,
он остается активным объектом, не только обрабатываемым, но и обрабатывающим
- ведь он носитель программных услуг!
Второе фундаментальное изобретение основано на наблюдении, что активный
объект может предоставлять услуги и по извлечению и(или) преобразованию
значений собственных атрибутов - это совершенно естественно для
унифицированной концепции объекта (и типа). Но в такой ситуации становится
удобным ЛЮБУЮ программную услугу (действие, операцию, подпрограмму, ресурс)
рассматривать как принадлежащую конкретному объекту некоторого типа. И
управление предоставлением и развитием услуг становится столь же гибким, как
управление любыми другими атрибутами объектов (или столь же негибким!).
Так мы приходим к тому, что в последние годы привлекает всеобщее
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
