Бертран Мейер - Основы объектно-ориентированного программирования

[x]. f экспортируется в классе A и в классе B (хотя и не обязательно одним и тем же клиентам);

[x]. f скрыто в A и B ;

[x]. f скрыто в A , но полностью или частично экспортируется в B ;

[x]. f экспортируется в A , но скрыто в B .

Правило гласит: по умолчанию f сохраняет тот статус экспорта, которым компонент был наделен в A . Однако его можно изменить, добавив предложение exportв предложение наследования класса. Например:

class B inherit

A

export {NONE} f end

-- Скрыть f (возможно, экспортируемый в классе A)

...

или

class B inherit

A

export {ANY} f end

-- Экспортировать f (возможно, скрытый в классе A)

...

или

class B inherit

A

export {X, Y, Z} f end

-- Сделать f доступным определенным классам

...

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

Представим себе GENERAL_ACCOUNT - класс, содержащий все необходимые операции для работы с банковскими счетами: процедуры open , withdraw , deposit , code (для снятия денег через банкомат), change_code и т.д.,- но не предназначенный для использования клиентами напрямую, а потому не экспортирующий никаких подпрограмм. Его потомки выступают как разные облики родителя: они не содержат новых компонентов и отличаются лишь предложениями экспорта. Один экспортирует open и deposit , второй, наряду с ними, - withdraw и code , и т. д.

Рис. 16.12. Разные облики одной абстракции

Эта схема в обсуждении методологии наследования (см. лекцию 6курса "Основы объектно-ориентированного проектирования") носит название наследования функциональных возможностей (facility inheritance).

Понятие облика (view) является классическим в области баз данных, где необходимо дифференцировать пользователей, работающих с данными, предоставляя им разные права.

Другой пример касается классов, введенных, когда речь шла о множественном наследовании. Компонент right класса CELL скрыт в нем или, точнее говоря, экспортируется лишь классу LIST . Фактически так обстоят дела со всеми компонентами CELL , поскольку этот класс был изначально нацелен на работу со списками. Однако в дереве (классе TREE ), потомке как CELL , так и LIST , right теперь означает доступ к правому брату и является респектабельным членом общества экспортируемых компонентов.

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

Предпринимались и иные попытки. Так, отдельные объектные языки определяют не только то, будет ли компонент экспортирован клиентам класса, но и то, будет ли он доступен его потомкам. Преимущества этого подхода неочевидны. В частности:

[x].мне не известно о публикации рекомендаций по применению этой возможности, неясно, когда компонент должен передаваться потомкам, а когда быть скрытым. Конструкции языка, за которыми нет ни малейшей теории, имеют весьма сомнительную ценность. (Для сравнения: правило, посвященное методологии скрытия информации, совершенно прозрачно: то, что принадлежит АТД, и надлежит экспортировать; прочее следует скрыть.)

[x].механизмы ограничения порожденных классов, введенные в языке Simula и др., редко используются разработчиками.

При близком рассмотрении отсутствие ясных методологических установок не удивляет. Наследование является воплощением принципа Открыт-Закрыт: позволяя выбрать готовый класс, написанный вами или другим программистом вчера или 20 лет назад, и обнаружить, что с ним можно делать нечто полезное, что даже не предполагалось при его проектировании.

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

Пример классов CELL и TREE характерен: при разработке CELL его целью была лишь поддержка работоспособности LIST , а потому right и put_right служили в нем исключительно внутренним целям. И лишь позднее этим компонентам нашли новое применение в классе-потомке TREE . Не будь этой открытости, наследование почти полностью утратило бы свой шарм.