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

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

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

наследования.

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

операциях.

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

в него попадает лишь частично - обогащенным объектом можно замещать источник

присваивания, но не получатель.

5. Все экземпляры (объекты) одного типа обладают идентичными атрибутами

(но не их значениями!).

Следствие: индивидуальные свойства объектов (определяемые, в частности,

значениями атрибутов) не наследуются и по наследству не передаются.

6. Наличие наследников не влияет на атрибуты родителя.

Следствие: свойство "иметь наследников" не считается атрибутом (и,

стало быть, не наследуется).

7. Атрибуты могут быть абстрактными (виртуальными) и тем самым

требовать конкретизации (настройки на контекст перед использованием или в

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

требовать.

Пример абстрактного атрибута - поле "С" в типе "Сети". Его

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

например, Сеть1.С. Пример конкретного атрибута типа "Сети" - процедура

Удалить.

8. Результат конкретизации абстрактных атрибутов в общем случае

определяется тем контекстом, где объекты создаются.

Следствие: поскольку в этот контекст входят не только типы, но и

конкретные объекты (экземпляры типов), то конкретные значения абстрактных

атрибутов могут зависеть от свойств конкретных объектов контекста, а не

только от их типов.

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

(инициализации) объектов. Например, объект-очередник при создании получает

конкретное значение атрибута, указывающего на стоящего впереди объекта.

9. Накопление в некоторых ЯП может состоять как из абстрактных, так и

из конкретных атрибутов (Смолток, Оберон, Турбо Паскаль 5.5), а в других -

только из конкретных атрибутов (Ада).

Следствие: в ЯП второй категории значения атрибутов не могут учитывать

свойства (и даже сам факт существования) объектов таких типов, которые не

существовали в момент написания (трансляции) программы.

Итак, операции-атрибуты Ады могут служить примерами конкретных

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

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

конкретные функции и процедуры) никак не зависят от экземпляров объектов

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

при создании объектов. Более того, из-за ограничений строгой типизации в Аде

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

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

Упражнение. Докажите неформальную теорему, сформулированную в последнем

предложении предыдущего абзаца.

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

комбинированных типов (в любых ЯП, где есть наследование). Их естественно

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

а конкретные значения этих атрибутов (т.е. конкретные поля конкретных

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

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

связь с объектами индивидуальна.

В тех ЯП, где атрибуты-поля входят в накопление (Симула-67, Оберон,

Турбо Паскаль 5.5 и др.), в объекты производных типов могут входить поля,

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

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

(производные) типы, строгая типизация не мешает их формированию, в отличие

от ситуации, когда в накоплении допустимы только конкретные атрибуты (Ада).

Во-вторых, примерами абстрактных атрибутов служат виртуальные операции

(операции Симулы-67, правила (методы) Турбо Паскаля 5.5, Смолтока и др).

Подробнее о них - в следующем разделе.

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

концепции наследования в современных ЯП. Например, в Модуле-2 наследование

отсутствует совершенно (хотя можно усмотреть его зачатки в связи модулей по

импорту), в Аде - наследование только с конкретным накоплением, в Обероне -

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

Турбо Паскале 5.5 нас ждет почти идеальное наследование. "Почти" потому, в

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

обогащении составных типов.

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

с Обероном, возможно, мучает вопрос о правомерности (или неправомерности)

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

операций к новым объектам. Можно, конечно, искать общий ответ, и мы

предложим на этот счет некоторые соображения. Однако не менее интересно и

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

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

ориентированном программировании. Действительно, пусть сами объекты

"решают", с кем им нужно взаимодействовать, а с кем - нет.

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

программированием, укажем еще раз на преимущества развитой наследуемости.

18.8. Преимущества развитой наследуемости.

1. Гармония открытости и защиты.

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

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

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

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

создателем.

Гармония состоит в том, что, с одной стороны, развитый аппарат

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

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

другой стороны, ни одно из этих преобразований не способно нарушить

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

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

сочетается с идеальной надежностью (при вполне приемлемой эффективности и

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

тиражируемости программных изделий).

2. Поддерживаемая технология развития программной системы (пошаговая

модификация работающей основы) способствует оптимизации и структуризации

мышления, программирования, памяти.

3. Эта технология полностью согласуется с концепцией "расслоенного

программирования" А.Л.Фуксмана [#5], описанной им более десяти лет назад

(пошаговое наращивание новых "слоев" работающей версии программы от

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

4. Поддерживаемый стиль мышления адекватен естественному развитию от

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

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

лишь пошаговую детализацию сверху-вниз).

5. Говоря более конкретно, развитое наследование обеспечивает

расширяемость объектов, типов и операций с защитой авторского права и с

гарантией сохранности старых программ. Можно воспользоваться программой,

развивать ее, но нельзя украсть "секреты фирмы", если они скрыты автором.

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

наследования от аналогичного понятия из "реальной жизни". В последнем случае

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

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

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

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

конечно, неисчислимым множеством свойств, никак не охватываемых

соответствующим типом) . А в информатике и типы, и экземпляры объектов

представлены вполне реальными разрядами, записями, фреймами и т.п.

Соответственно и наследование пока представлено как определение и обработка

определений типов, а не результат "жизнедеятельности" объектов. Однако нет

оснований полагать, что так будет всегда.

18.9. Наследуемость и гомоморфизм (фрагмент математической позиции)

Преамбула.

В разделе об авторской позиции было предложено упражнение (повышенной

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

непосредственно связано с наследуемостью. Конечно, речь идет о гомоморфизме.

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

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

встречать упоминание об этом в литературе.

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

В.А.Левину. Когда он впервые рассказал на нашем семинаре в МГУ о своем языке

спецификаций Атон [33], существенно уточняющем и развивающем V-подход [34],

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

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

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

соответствующий раздел книги.

А для В.А.Левина, занятого математической формализацией содержательных

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

какое именно математическое понятие следует сопоставить наследованию.

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

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

обсуждать и другие возможные роли гомоморфизма в программировании. Так что

следующие ниже соображения можно считать результатом наших совместных

обсуждений.

Суть дела.

Для начала напомним, что гомоморфизм g из области отправления P в

область прибытия Q - это отображение

g: P-->Q

типа P-->Q, где P и Q - алгебры (алгебраические системы), для которого

выполнено определяющее соотношение

g*f = g(f)*g

для всякой операции f из P (звездочкой обозначена композиция отображений).

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

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

мы уже поступали в модели Б.

Итак, гомоморфизм - это отображение, сохраняющие свойства всех операций

из области отправления (в том смысле сохраняющее, что, во-первых, каждой из

них соответствует некоторый "гомоморфный образ", и, во-вторых, результат

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

операции к гомоморфному образу ее аргумента).

Основное свойство гомоморфизма можно представить следующей

коммутативной диаграммой.

результат:f(X) -----> образ результата:g(f(X))=g(f)(g(X))

/^\ /^\

f: I g(f): I

I I

аргумент:X -----> образ аргумента :g(X)

Коммутативность диаграммы означает, что из ее левого нижнего ула в

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

результатом.

Обычно гомоморфизм объясняют как отображение из "богатых" структур в

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

структур. Но для нас особенно интересна (обратная, двойственная)

интерпретация гомоморфизма как отношения между "бедной" и "богатой"

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

первой операций. В сущности, это и есть отношение идеального наследования!

Достаточно посмотреть на наш идеал наследования и на определяющее

гомоморфизм соотношение или на коммутативную диаграмму.

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

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