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

Смена имен подчеркивает важность именования - как компонентов, так и классов - в практике ОО-разработки ПО. Формально, класс - это отображение имен компонентов в сами компоненты. Компоненты известны остальному миру благодаря именам.

В последней лекции будет дан ряд правил выбора имен компонентов. Заметим, что предпочтение следует отдавать общеизвестным именам: count, put, item, remove, ... - выбор которых подчеркивает общность абстракций, существующую, несмотря на объективные различия классов. Придерживаясь этого стиля, вы увеличите вероятность конфликта имен при множественном наследовании, но отчасти избавитесь от переименований, имевших место в случае с классом WINDOW . Но каким бы правилам не отдавалось предпочтение, должна быть обеспечена гибкость в подборе имен, отвечающих потребностям каждого класса.

Еще один пример иллюстрирует типичный случай переименования процедуры создания класса. Вспомните класс ARRAYED_STACK , полученный порождением от STACK и ARRAY . Процедура создания ARRAY размещает в памяти массив с заданными границами:

make (minb, maxb: INTEGER) is

-- создать массив с границами minb и maxb

-- (пустой если minb > maxb)

do ... end

Для создания стека необходимо создать массив, позволяющий вместить заданное число элементов. Реализация основана на процедуре создания ARRAY :

class ARRAYED_STACK [G] inherit

STACK [G]

redefine change_top end

ARRAY [G]

rename

count as capacity, put as array_put, make as array_make

end

creation

make

feature -- Initialization

make (n: INTEGER) is

-- Создать стек, допускающий размещение n элементов.

require

non_negative_size: n >= 0

do

array_make (1, n)

ensure

capacity_set: capacity = n

empty: count = 0

end

... Другие компоненты ...

invariant

count >= 0; count <= capacity

end

Заметим, что выполнение соглашений об именах - выбор make как стандартного имени базовой процедуры создания - привело бы к конфликту, который, впрочем, не возникает благодаря переименованию, устраняющему заодно двусмысленность в отношении count и put . Оба имени встречаются в каждом классе.

Смена имен - лишь одно из средств, используемых мастером наследования для построения полноценных классов, удовлетворяющих потребностям своих клиентов. Другим таким средством является переопределение. В этой и следующей лекции мы увидим еще несколько таких механизмов: отмену определений (undefinition), соединение (join), выделение ( select), скрытие потомков (descendant hiding). Мощь этих комбинируемых механизмов делает наследование излишне заметным, поэтому иногда возникает необходимость в существовании версии класса, свободной от наследования, - плоской форме (flat form).

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

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

Эту задачу решает плоская форма класса. Но вам не придется ее создавать. Ее построит один из инструментов среды разработки, который можно запустить, введя команду сценария ( flat class_name) или щелкнув по соответствующей пиктограмме.

Плоская форма класса C - это корректная запись класса, имеющая, - с точки зрения клиента, не использующего полиморфизм, - ту же семантику, что и класс C , но лишенная всех предложений наследования. Именно так выглядел бы любой класс, если бы его создатель не мог пользоваться наследованием. Построение плоской формы предполагает:

[x].устранение предложения inherit, если оно есть;

[x].сохранение в неизменном виде всех определений и переопределений из C ;

[x].введение в класс объявлений всех унаследованных компонентов, скопированных из соответствующих классов-родителей, с учетом всех указанных в inheritпреобразований: переименования, переопределения, отмены определений, выделения ( select), объединения компонентов;

[x].добавление к каждому унаследованному компоненту строки комментария вида: from ANCESTOR, где указано имя ближайшего предка, (пере)определившего компонент (а в случае объединения компонентов - победившая сторона);

[x].восстановление полной формы предусловий и постусловий унаследованных методов (по правилам наследования утверждений, изложенным в следующей лекции);

[x].восстановление полного инварианта класса как конъюнкции ( and) всех родительских инвариантов с последующим преобразованием в случае применения переименованных или выделенных компонентов.

Полученный в результате класс содержит все компоненты оригинала, как введенные в самом классе, так и полученные им от предков (вторая категория компонентов от первой отличается лишь комментарием). В случае наличия меток в секциях объявления компонентов, например, feature- Access, подобные метки остаются. Секции с одинаковыми метками объединяются. В каждой секции компоненты выстраиваются по алфавиту.

На рисунке показана часть плоской формы класса LINKED_TREE из библиотеки Base. Результат получен с применением Class Tool в среде разработки ISE. Для повторения результата настройте Class Tool на LINKED_TREE и щелкните по кнопке формата Flat.

Рис. 15.14. Отображение плоской формы

Плоская форма класса - ценный инструмент разработчика. Именно она позволяет увидеть все компоненты класса, собранные в одном месте, игнорируя то, как они были получены в играх с наследованием. При чтении текста класса трудно бывает понять, что стоит за именем каждого из его компонентов. Это один из недостатков наследования. Плоская форма класса решает эту проблему, формируя полную картину происходящего.